fix(agent): validate put at the daemon boundary; state the two scope semantics (L-5, L-6, L-7)

L-7 — `put` is the only way a fingerprint enters `held`, and every later
handler joins that string onto a path (the vault it opens, the audit log it
writes). The CLI validated the format first, which is exactly why the daemon
could not rely on it: agent.ts's own header says the CLI is untrusted, and the
browser extension speaks this protocol next. `put` now requires 16 uppercase
hex, and additionally that the fingerprint actually belongs to the supplied
seed — a mismatch would unlock a vault the caller did not name and file its
audit records under the wrong profile.

Validation order matters and is now deliberate: cheap format check, then ttl,
then the seed match last, because deriving a fingerprint runs the BIP-39 KDF
and a malformed ttl should not pay for it. This keeps the existing
non-numeric-ttl test exercising the ttl path rather than short-circuiting on
the new check.

L-5 — `label_regex` is unanchored, so a token issued for `prod` also reaches
`not-prod-db`. Left as-is on purpose: Python matches with `re.search`, so
anchoring the TypeScript side alone would make one token mean two different
things depending on which implementation holds it, and would silently narrow
every token already issued. The audit asked for whichever behavior Python has,
documented and in the parity matrix — so the semantics are now stated in
--label-regex help, reported machine-readably as
capabilities().tokens.label_regex_semantics, explained at the enforcement
point, recorded in the compatibility matrix, and pinned by tests that assert
BOTH labels are visible to an unanchored token.

L-6 — the exec allowlist constrains the command word, never its arguments.
The token holder writes the argv and the child gets the secret in its
environment, so an allowlisted binary with an output-file or network flag
hands the secret straight back. Documented in the same three places rather
than changed: argument-level containment means allowlisting full argv
templates instead of command words, which is a token-format change that has to
land in both implementations together.

Tests: malformed and mismatched fingerprints refused with nothing held (path
traversal, wrong case, wrong length, trailing component); unanchored vs
anchored label_regex; capabilities reporting both semantics. Mutation-verified
— disabling either put guard turns the matching tests red.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Claude-Session: https://claude.ai/code/session_01Vtx94nXDmNgXEeThUZP4QN

docs/typescript_port_compatibility_matrix.md

@@ -116,6 +116,18 @@ need a versioned protocol change in both implementations:
    numbers (or an info string) and a compatibility version, since existing
    keys must keep deriving as they do.
 
+**Deliberately identical, and wider than it reads: token `label_regex`.**
+Both implementations match a token's `label_regex` as a *search*, not a full
+match — Python with `re.search` (`src/seedpass/cli/agent.py`), TypeScript with
+`RegExp.test` (`js/packages/cli/src/agent.ts`). A token issued for `prod`
+therefore also reaches `not-prod-db`. Anchoring the TypeScript side alone
+would make one token mean two different things depending on which
+implementation holds it, and would silently narrow the scope of every token
+already issued, so the semantics stay as they are and are stated instead: in
+`--label-regex` help, in `capabilities().tokens.label_regex_semantics`, and
+pinned by tests in `js/packages/cli/test/tokens.test.ts`. Operators wanting an
+exact match anchor the pattern themselves (`^prod$`).
+
 **Resolved:** TOTP codes for entries with a non-default period/digits used
 to differ — Python built `pyotp.TOTP(secret)` with library defaults and
 ignored the entry's recorded values, so an imported 8-digit/45s secret