fix: request_apply_commit resolves sha locally + rejects non-sha refs

CLAUDE.md

@@ -183,6 +183,24 @@ read them à la carte.
 In-flight or recent context that hasn't earned a section yet.
 Prune freely.
 
+- **Just landed:** `request_apply_commit` fetch fix. The old
+  `git_fetch_to_tag` built a refspec `<sha>:refs/tags/proposal/<id>`
+  and ran `git fetch <proposed> <sha>:...` — but `git fetch` resolves
+  the left side of a refspec as a remote *ref name*, and a bare
+  commit sha is not one ("couldn't find remote ref ..."). Fetching
+  by sha would need a full 40-hex sha plus
+  `uploadpack.allow*SHA1InWant` on the remote. Surfaced on the first
+  real `request_apply_commit` (the `gui` agent bootstrap — initial
+  `deployed/0` seeding uses a different path). Fix: `git_fetch_to_tag`
+  now resolves the sha LOCALLY against the proposed repo
+  (`git rev-parse <sha>^{commit}`), fetches all of proposed's heads
+  into applied's object db (`+refs/heads/*:refs/remotes/proposal-src/*`),
+  then `git tag`s the resolved sha — all-local, no upload-pack
+  sha-want negotiation. Plus: `submit_apply_commit` now shape-checks
+  `commit_ref` is a 7-40 char hex sha (`validate_commit_ref`) and
+  rejects branch/tag names so the proposal always pins an immutable
+  commit. Tool description + `RequestApplyCommit` wire doc +
+  `docs/approvals.md` updated. 3 new tests in `manager_server::tests`.
 - **Just landed:** inbox batching unified into `recv(max?)`.
   No separate `recv_batch` tool — the existing `recv` tool
   grew an optional `max: u32` arg (default 1, server-side