ucan: no depth, proof-count, or size budget on verify_chain allows oversized pre-handler verification work

[euxaristia]

Summary

Ucan::verify_chain (crates/gitlawb-core/src/ucan.rs:252-292) recurses through prf with no depth, proof-count, or per-chain size budget. Every linkage it checks is satisfiable by self-minted chains: proof.aud == self.iss holds by construction, and */* attenuates under */* (ucan.rs:52-60). require_ucan_chain runs before handlers on every write route group (crates/gitlawb-node/src/server.rs:49-56), and only creation_routes carries rate limiting (server.rs:92-112) - the remaining write groups are unlimited.

Impact

A crafted X-Ucan header within hyper's default header cap drives verified CPU cost into the tens of milliseconds per request ahead of any handler (measured offline against gitlawb-core; harness available on request), and headers are replayable (#253). On the write groups without rate limits this is a pre-handler CPU sink with no configuration bound. Nested chains cannot reach crash depth - each nesting level JSON-escapes the one below, so growth is self-limiting within the cap; the issue is unbounded per-request verification work, not memory or stack exhaustion.

Remediation

1. Cap chain depth, proof count, and per-token size before walking prf; reject oversized X-Ucan headers early.
2. Carry the same budgets into feat(node)!: anchor the UCAN proof chain and honour delegated git/push #331's anchored verification.
3. Optionally cache (signer, token-hash) validations so replayed headers do not re-verify.