## Summary
Revision 36 closes the sole Stage-35 reserve/verify blocker. It moves immutable diagnostic-reservation creation, authoritative body/destination validation, and reread verification into one `DiagnosticHost._admission_lock`-held authority operation before provider admission, preserving the prior close/detach linearization.

## Claims
- The immutable index binds the reviewed revision to SHA-256 `c70c3217cba0becbcd2bbcc836b5fb1af8f6e9d44608e43dda17a1d0277d99f0` (`plans/ralplan/019f8455-334a-7000-99ca-318dfd0e06b1/index.jsonl:47-48`).
- Stage 35 required verification of an already-existing reservation, while its host sequence called verification before unspecified admission creation (`stage-35-revision.md:75-84`).
- Revision 36 replaces that request/verification model with a non-authorizing `DiagnosticDeliveryCandidate` and `DiagnosticDeliveryAuthority.reserve_and_verify(candidate, *, lock_token)` (`stage-36-revision.md:108-112`).
- Under the host admission lock, the new operation reloads and validates every current pin, rejects candidate/body/destination mismatches before rows, appends the immutable reservation under the adaptive store lock, rereads that exact row, and returns only reservation-pinned bytes/destination (`stage-36-revision.md:114-121`).

## Analysis
### Spec compliance
The former impossible call order is removed. `DiagnosticHost.deliver(candidate)` now owns the sequence: reserve-and-verify, immediate provider-start revalidation, frozen diagnostic transport, then durable receipt/delivered/audit terminalization; cancellation and timeout use the authority terminalizer before the admission lock releases (`stage-36-revision.md:121-123`). The ordinary coordinator reservation branch is expressly bypassed, so it cannot recreate a pre-host reservation gap.

### Architecture
The host is the correct reservation owner because it alone serializes delivery with close, expiry, and stop. If close wins, validation fails before any row or provider work; if reservation wins, detachment cannot append until the attempt reaches a durable terminal result. The candidate carries all named durable pins but grants no provider authority; only the authority-generated verified reservation reaches the frozen transport.

The retained restart and duplicate contracts remain fail-closed: exact terminal/consumed duplicates produce a typed no-send result, conflicting dedupe keys reject, and a post-reservation crash must not resend. Required deterministic tests cover candidate validation, both close/reserve orderings, crash recovery, duplicates, pin/body/destination mismatches, and one exact successful chain (`stage-36-revision.md:121-125`).

### Antithesis and synthesis
Keeping reservation creation in the child coordinator would reduce extraction work but reintroduce the Stage-35 check-to-reserve gap outside the host lock. The selected narrow authority operation retains the existing adaptive-store transaction while making the host lock the only delivery linearization boundary.

## Root Cause
Resolved: Stage 35 treated reservation creation as an unspecified operation after verification, although verification required the row to exist. Revision 36 makes reservation creation and verification a single host-owned operation.

## Findings
None. No `report_finding` calls were made.

## Recommendations
Proceed with the cumulative Stage-33/35/36 implementation. Preserve the exact host-held ordering and the provider-zero assertions for validation failure and close-first interleavings.

## Architectural Status
CLEAR

## Code Review Recommendation
APPROVE

## Tradeoffs
- **Host-owned reserve-and-verify (chosen):** one durable linearization point; preserves close/provider ordering and sealed body/destination authority.
- **Coordinator reserve before host delivery (rejected):** lower refactor cost but restores a pre-host close race.
- **Verify before reserve (rejected):** cannot succeed because the prerequisite row does not exist.