refactor(daemon): split the /rpc request-end handler into its four questions
Summary
The /rpc request-end callback owned body framing, envelope validation, admission, the handler run, answer serialization and cleanup in one 205-line arrow: CRAP 45, CC 45, cognitive 40, 96% covered.
Split into the four questions the flow asks, each a named top-level unit: validateRpcRequestEnvelope (bytes → a sound call or a refusal), admitRpcRequest (whether the caller may run it; the gate order is the security contract), beginRpcRequestLifetime (tracking id, disconnect watch, settled marker, release), invokeAdmittedRpcRequest (runs, answers, ends the lifetime).
They stay in http-server.ts, not new files: ADR 0027's tolerance compares module-scope statement weight, and hoisting code out of a closure always adds some — the smallest extraction here, one function in one new module, fails the eager-closure gate at +1/+1. In a module the closure already evaluates, it adds none. Admission aimed at http-authorization.ts, but that needs http-rpc-methods.ts, which already imports authorization: a value cycle.
After: 12 (front door, CC 12) / 11 / 8 / 7 / 5. Order preserved: the tracking id registers ahead of the auth hook, an answer already begun is never a disconnect, and the invoked request releases its lifetime the turn its handler resolves.
Validation
Head 1864d6cf5; gross 944 lines (705+/239-, 5 files).
check:affected --run— GATE_EXIT=0vitest run scripts/__tests__/eager-closure-budgets.test.ts— passes (Coverage-only on CI)check:coverage-crap --base origin/main— none at or above 30check:fallow --base,check:layering, lint/typecheck — clean- provider scenarios
daemon-http-server/-disconnect/-boundary-cancellationpass