Make sure invalid path errors appear clearly in IOC console

[GDYendell]

When a start writing command is sent to the odin server with an invalid path set, it returns a 503 and logs

[Fri Sep  5 16:23:54 2025][E 250905 16:23:54 frame_processor_adapter:203] Error: Invalid path specified [/dls/i02_1/data/]

but ADOdin just prints

2025/09/05 16:23:54.527 RestParam[ODIN_HDF5_WRITE -> write]::basePut: Underlying RestAPI put failed

Make sure we print a useful error here. Things to check

• The response contains a useful error
• Errors from the FPs about invalid file paths are reported, even if the path exists in the control server (which could be on a different machine)

The first step is to reproduce the problem with fastcs-odin running in debug and check what the HTTP response is for

• sending a bad file path
• sending a start writing command with a bad file path

Dev environment:

• podman run --rm -it -v /dev/shm:/dev/shm --net=host ghcr.io/diamondlightsource/eiger-detector-runtime:latest
• fastcs-odin in devcontainer, launch Odin IOC

If we don't get nice responses, create an odin-data issue to fix it and pause this issue.

Acceptance Criteria

• A clear error is logged when an invalid path is used

[ajgdls]

Current behaviour:
When the configuration containing an invalid path is sent to a FrameProcessor, the reply comes back from the C++ FP application with an error.
In the adapter running inside the Odin Control server, the error response is received and the adapter records the error condition:

http localhost:8888/api/0.1/fp/0/status/error
HTTP/1.1 200 OK
Content-Length: 44
Content-Type: application/json; charset=UTF-8
Date: Wed, 18 Feb 2026 14:23:05 GMT
Etag: "02eb4ceb1e6e763227159a9210b0a6e1e01fd40b"
Server: TornadoServer/6.5.4

{
    "error": [
        "Invalid path requested: /tmp4"
    ]
}

This currently happens outside the processing chain of the original HTTP PUT request.

The adapter is returning immediately without blocking any PUT requests, and it returns with no error at that time.
At some later time when the error response is returned from the underlying FP application it is added to the adapter's error status item as shown in the snippet above.