Offer a git staging control only where the server proved a slot

[benfavre]

Closes the last open item of #128: the combined review can now stage, unstage, commit and resolve conflicts, at file level.

The read side has shipped since PR #159 — ReviewFile already carried worktree, conflict, the hunks and the preview metadata, so a partially staged file appeared on both sides and an unresolved conflict was listed only as a conflict. Only the mutations were missing, and #159 and #160 reached the same conclusion independently from opposite directions: ReviewCapabilities advertised nothing that could fence a staging write, so a stage could only have gone out unconfirmed and uncorrelated, and an ambiguous outcome would have been reconcilable by nothing but an uncorrelated key search. That is precisely what the confirmed lane exists to avoid.

bext-stack/automonique PR #225 built the missing fence, and this consumes it.

What arrives on the wire

Two lists on ReviewCapabilities. Each entry names the commit HEAD the server's preflight resolved to and a digest over the whole index it read, because a worktree is shared substrate: another process running as the daemon uid can move either between the advertisement and the action, and the snapshot revision only tracks what the projection observed. The four actions moved into requires_confirmation, so their unconfirmed spelling no longer encodes on either side.

Absence is the withholding

The three staging kinds share one capability type but not one grant — an operator installs index writes, committing and conflict resolution independently. A deployment that grants stage and unstage but not commit therefore advertises two entries, and the commit proposal keeps its observation badge and grows no button. Not a disabled one with a tooltip: a disabled control claims the grant is present and merely unavailable, which is the opposite of what the list says.

SDTEST-1867 demonstrates that rather than asserting it. One run: the withheld commit answers false at the projection, refuses at the preview constructor, and stays visible as an observation; both granted siblings go end to end to a confirmed preview carrying the server's own digests verbatim, still admitted by a re-read of the capability. Then the commit grant is installed and the third control appears from unchanged projection code. Mutation-checked — forcing advertises_staging to true fails it on the intended line.

conflict_resolutions lists one entry per side git actually recorded, because the side decides which blob lands and is therefore inside the confirmation digest. A file holding both stage 2 and stage 3 renders two buttons; a delete/modify pair renders one (SDTEST-1869, which proves the two previews carry different confirmations — that is what makes them unswappable).

Withdrawing locally rather than being refused

The server mints the confirmation over the commit HEAD, the whole index and every named path, so comparing that digest against a fresher capability document is the head-and-index comparison; restating a subset of it separately would add nothing. Every staging preview therefore reports requires_capability_revalidation, and a moved worktree stops matching before anything reaches the daemon (SDTEST-1868). The observation is exposed on the projection and rendered, so a reader can see the fence rather than trust that one exists.

Receipts are polled through GetReviewReceipt with the correlation digest — lookup_review_action already routes that for any confirmed preview. Re-sending the action would be pointless anyway: the write invalidated the confirmation it was minted with.

Two things this had to touch beyond the obvious

The confirmation guard was a local restatement of the contract. review_action tested matches!(action, RerunCheck { .. }) rather than asking requires_confirmation(). The confirmed set grew from one member to eight with this protocol revision, and the stale spelling had already gone wrong for merge_pull_request, which was minting previews the transport could no longer encode. That constructor now takes its capability the way the rerun does, so it refuses honestly instead of failing at the wire. The server still ships the merge slot empty, so nothing changes in production.

custody.rs did not understand these four families. prepare would have returned UnsupportedAction and the dispatch would have died at the fence — the same defect PR #161 found for the batch delivery after PR #160 asserted the format already knew "these actions". It knew the two it named. The disk enum now spells each staging kind separately, because a recovered plan re-readable as another kind would let a narrower grant replay as a wider one, and a conflict resolution persists its side because the side is part of the effect's identity. SDTEST-1870/1871 drive the whole store rather than only the enum.

Hunk granularity: not built, not faked

ReviewProposal lists file ids, a staging action names a proposal, and ReviewAnchor's hunk id exists for comments only. File-level staging is all the contract can express, so that is what ships. The #128 item ticks for the file half; the hunk half needs a protocol addition — a hunk-scoped proposal or action, plus a hunk identity stable enough to fence a write on — and should be tracked separately.

Coverage

SDTEST-1867..1873, rows in docs/testing/tests-core.md and tests-ui-and-app.md, plus a ## Change log entry amending SDUC-495. SDTEST-1848 is retired rather than deleted: it pinned the reason staging had no control, and that reason is gone.

Verification

cargo test --workspace --exclude shelldeck-ssh, cargo clippy --workspace --no-deps -- -D warnings, cargo fmt --all -- --check. The lockfile diff is the two automonique-* source lines and nothing else.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Nf2PAqdKZxRuZSYGq3NE6o