test(node): submit_bounty claimant gate is a vacuous guard; harden every_in_scope_mutation_has_its_gate

[beardthelion]

Surfaced while generalizing the mutation-gate completeness guard in #195.

every_in_scope_mutation_has_its_gate asserts a did_matches( substring is present in a handler body, not that it is the load-bearing enforcement site. submit_bounty (crates/gitlawb-node/src/api/bounties.rs:302-306) binds let is_claimant = ...did_matches(...) on one line and enforces with if !is_claimant { return Forbidden } below it. Deleting the enforcement if leaves the did_matches( marker in place, so the guard stays green, and submit_bounty is a non-repo-scoped POST, so neither the repo-scoped guard nor the mounted-route (GET) completeness gate added in #195 covers it. A regression dropping the claimant check would let any authenticated DID submit any claimed bounty with the suite fully green.

approve_bounty/cancel_bounty place did_matches( inside the enforcement if, so deletion trips the marker, but a wrong-principal swap (creator/claimant) would still pass, since nothing drives their arm.

Fix options:

• Drive submit/approve/cancel_bounty as single-arm 403 rows in the deny-prober so each arm is executed.
• And/or harden every_in_scope_mutation_has_its_gate so the required marker is the enforcement expression rather than any substring occurrence.

[beardthelion]

Root cause of why the invariant gate misses this (reproduced by execution: neutering submit_bounty's if !is_claimant gate left the full deny_harness suite at 33/33 green).

submit_bounty falls through all three nets of the gate:

1. Runtime deny-sweep (deny_bearing_routes, tests/support/routes.rs) drives only handlers classified as deny-bearing (403/404/401). submit_bounty is classified positive-by-design (src/api/mod.rs:216, Bucket D), so it has no row and is never probed. test(node): invariant deny-prober (driven registry + completeness cross-check) #195 added dispute_bounty as a deny row but left submit/approve/cancel as marker-only.

2. Read-side completeness (mounted_repo_gets_are_driven_excused_or_declared_public, tests/deny_harness.rs) derives its set from the mounted route table, but gates on if method != "GET" || !is_repo_scoped_path(path). submit_bounty is a POST on a non-repo-scoped path (/api/v1/bounties/{id}/submit), excluded twice over.

3. Mutation-side completeness (every_in_scope_mutation_has_its_gate, src/api/mod.rs:168) does list it (:218), but asserts body.contains("did_matches(") (:242) over a hand-maintained list (:185-230). submit_bounty binds let is_claimant = ...did_matches(...) on a line separate from its enforcement if (bounties.rs:302 vs 304), so deleting the if leaves the substring in place and the guard stays green. It checks the marker exists, not that it is the enforcement site or binds the right principal.

The one-sentence cause: the completeness-guard lessons #195 applied to READS (derive the required set from the route table; the guard must go RED when the enforcement line is reverted) were never applied to the MUTATION side, which predates #195 as a hand-list + substring-presence check. The read gate is load-bearing by construction; the mutation gate is presence by construction. approve/cancel happen to place did_matches( inside the enforcement if, so deletion trips their marker, but that is a coincidence, not a designed property.

Gate-level fix direction (not just three rows):

• Derive the mutation required-set from the route table (extend scrape_mounts to non-GET / non-repo-scoped) so a new lifecycle mutation cannot be silently omitted from a hand-list.
• Bind the check to enforcement, not presence: give submit/approve/cancel_bounty single-arm 403 rows in the deny-prober (exactly what dispute_bounty got in test(node): invariant deny-prober (driven registry + completeness cross-check) #195), so reverting each principal check goes RED by execution. Substring-presence cannot be made load-bearing; only a driven probe can.
• Extend the completeness net past GET + repo-scoped so POST / non-repo-scoped handlers have a home.

Note: comment_only_marker_does_not_satisfy_a_row (mod.rs:252) shows the substring check's weakness was already known and one evasion (comment-only markers) patched. A live-but-non-enforcing marker is the same class, unpatched.