ci: auto-patch miden-client dep from PR description marker (next)

[WiktorStarczewski]

Summary

Add an "auto-patch" system that lets a web-sdk PR pin its CI build against an in-flight miden-client PR by adding a single line to its description:

Client PR: #<NUM>

A composite action (.github/actions/inject-linked-client-pr) parses the marker, resolves the linked PR's head ref, and rewrites web-sdk's miden-client (and miden-client-sqlite-store) dep in place — only on the runner, never committed. Replaces the manual [patch] / branch-edit dance every cross-repo migration PR has been carrying.

What's in this PR

Path	Purpose
.github/actions/inject-linked-client-pr/action.yml	Composite action: parse, resolve, validate, rewrite, comment.
.github/workflows/build.yml, test.yml	Wire the action into the cargo-compiling jobs. build-wasm is the single sticky-comment poster (every other invocation has comment: false).
.github/workflows/check-linked-client-pr.yml	Mergeability gate. Keeps a linked-client-pr-ready check pending until the linked client PR is merged-and-reachable from the target branch's canonical refs. Re-evaluates every 15 min via cron.
scripts/dev-with-client-pr.sh	Local-dev mirror: applies the same rewrite to your working tree. --clear restores byte-for-byte.
lefthook.yml	Pre-commit guard: refuses any commit while the marker block is present.
CLAUDE.md	Docs: marker convention, local script, mergeability gate.

Why in-place rewrite, not [patch.crates-io] / [patch."<url>"]

Web-sdk's next pins miden-client to git=…miden-client.git, branch=next. Cargo's [patch."<url>"] errors with patches must point to different sources when the patch source URL matches the original — so we can't redirect the same URL to a different branch via [patch]. [patch.crates-io] doesn't apply on next either (the dep isn't a crates.io source there). In-place rewrite covers both main (crates.io) and next (git+branch) uniformly. The rewritten line is wrapped in marker comments preserving the original verbatim, so --clear (and the auto-cleanup if the marker is removed from the PR body) restores byte-for-byte.

Comment lifecycle

Strict 0-or-1 comment per PR:

• Marker present → sticky upsert via header: linked-client-pr (re-runs update in place, never duplicate).
• Marker removed → action deletes the stale comment.
• Closed-without-merge linked PR → workflow fails loudly with a clear summary; no comment posted (the failure surfaces in the run).

Test plan

• Open this PR — no marker; CI runs against canonical deps; no comment posted.
• Open a separate test PR with Client PR: #N in the body where #N is an open miden-client PR; verify:
  • Sticky comment appears once, summarizing the patch (head ref, sha, state, merged).
  • Cargo.toml on the runner has the rewrite (visible in build logs as branch = "<linked>").
  • Cargo.lock resolves to the linked PR's head sha.
  • The committed Cargo.toml on the branch is unchanged (no rewrite shipped).
• Edit the PR description to remove the marker; verify the sticky comment is deleted on the next run.
• Edit the PR description to point at a closed-without-merge PR; verify the run fails with the closed-PR error.
• On a linked PR that's merged-and-released: verify linked-client-pr-ready check goes green.

Migrations

Once this lands, the existing migration PRs (#23, #25, #26, #27, #29, #30, #31) can drop their hand-rolled [patch] / branch= edits in Cargo.toml and use the marker instead — see the description-only example I'll attach to one of them as the verification step.