manager socket: two response-ordering deviations from the protocol

[kp2pml30]

Found by a review pass over feat/rework-manager-api. Both are in implementation/src/manager/socket.rs, which is owned elsewhere — filing rather than patching.

1. run does semantic validation and module locking before allocating an ID

socket.rs:481, :491, :504.

The protocol (docs/website/src/impl-spec/appendix/manager-socket.rst:131) says the genvm_id is returned immediately and that request validation, permit acquisition and spawning complete asynchronously, with failures arriving as a terminal event.

In practice a request with non-empty host_hello_data[1], or one needing modules while modules are stopped, gets a direct error with no genvm_id and no terminal event. Module-lock acquisition can also delay the response.

Binary decode necessarily precedes ID allocation. But the semantic rejection classes should either move into supervision, or be documented as synchronous exceptions.

2. attach can enqueue a terminal notification before its own response

socket.rs:558, :582.

If a run finishes between taking the attach snapshot and sending the response, subscribe() spawns the forwarder before the response is queued; on a multithreaded runtime the forwarder can win and enqueue the terminal event first. The in-tree client expects the attach reply to be the next frame (tests/system/manager-socket/test.py:336) and fails.

Scheduler-dependent, but reachable. The run handler already does this correctly: retain the created receiver, enqueue the response, then start forwarding.

[kp2pml30]

robo-Kira: Part 2 is fixed on v0.6 — handle_attach now retains the receiver, sends the response, and only then calls subscribe, with a comment saying why (implementation/src/manager/socket.rs:596).

Part 1 still stands: handle_run rejects non-empty host_hello_data[1] and a modules-stopped request synchronously, before run_ctx.start allocates the id (socket.rs:493, :508), while manager-socket.rst:134 still says the id is returned immediately and validation failures arrive as a terminal event. Keeping open, narrowed to part 1.

[HusseinAdeiza]

Taking part 1.

On v0.6-dev the two synchronous rejections are live at implementation/src/manager/socket.rs:494 (host_hello_data[1]) and :509 (needs_modules with modules stopped), both ahead of run_ctx.start at :527, while manager-socket.rst:131 still says the id is returned immediately.

Worth noting for the fix: both conditions are already enforced inside supervision, at run.rs:2476 and run.rs:2380. The module-lock lookup in the socket path is not redundant though, it pins the handlers before spawn, so the lock stays and only the ordering moves.