fix(security): record WHY a CMB was refused, not a constant

[sym-bot]

CTO-approved instrumentation from the rejected-signature investigation. Note the repo: the brief said sym-core, but _rejectOnBadSignature lives here in @sym-bot/sym (lib/frame-handler.js). sym-core only supplies verifyCMB.

The problem

verifyCMB already distinguishes legacy-key-rejected / bad-signature / content-mismatch / no-public-key. Every one was recorded as the constant focusLabel: 'bad-signature', with the real reason going only to the console.

That makes every refusal on a node mutually indistinguishable — and on an active mesh this is the largest single verdict class. Separating them took a day of inference across three seats and still did not settle the mechanism.

These are dropped before SVAF evaluates, so they appear in no drift distribution and no admission tally — any complementarity figure is conditioned on the survivors, and the exclusion is not random (it removes a node's own operator and doer traffic).

Three changes, all in the one branch that writes this verdict

1. focusLabel carries v.error instead of the constant — the four verdicts become countable rather than inferable.
2. A pre-v1 key logs as version skew, not "forged/tampered". A substantial share of refusals are legacy-scheme keys from peers that simply have not upgraded. Logging those as forgery is wrong, and is the sort of thing noticed in a customer evaluation.
3. The decision records root vs remix. A rejected CMB is dropped and never stored, so this cannot be recovered from any store afterwards — it is captured here or not at all. The leading hypothesis (remix key derivation consuming envelope data the receiver does not hold identically) predicts these are overwhelmingly remixes; this boolean turns that from inference into a count.

The metric keeps reason: 'invalid' so existing consumers are unaffected; the specific verdict rides alongside as error.

Deliberately NOT touched — the fusion / re-signing path

The content-mismatch diagnosis that motivated it is not established for the population actually being dropped: across the rejected CMBs recoverable from a store, content-hash integrity was intact for roots, with too few remixes sampled to conclude from. Relay-key and key-churn were both excluded as mechanisms.

A supporting root-vs-remix integrity split was withdrawn under CTO challenge: it proved envelope-sensitive, swinging by an order of magnitude depending on which object is hashed. It evidences nothing and is not relied on here.

⚠️ Dependency note for review

This is most valuable with @sym-bot/core ≥ 0.4.0, which returns the granular v.error. main still pins ^0.3.49 while 0.4.0 is what is installed. The code degrades gracefully (v.error || 'bad-signature'), but the pin and the cutover branch should probably settle before this is relied on for counts.

Verification

296 tests / 295 pass. 4 new tests pin that a tampered CMB records content-mismatch, a spoofed one records bad-signature, the two are separable, the metric keeps its shape, and a remix rejection is flagged.

The single failure (memory-store "preserves the wire ancestor chain") is pre-existing on main — verified identical with the change stashed, deps held constant. It is the installed core 0.4.0 against main's ^0.3.49 pin, i.e. the cutover in flight.

⚠️ CI caveat, added later: the Node 18 matrix job has since hung twice for over six hours while Node 22 passes in ~30s. concurrency: cancel-in-progress records this as "cancelled" rather than "failed", so it is not visible in run history. Do not merge on the strength of the green Node 22 job alone.

Built in a worktree outside the repo; no live tree touched.

🤖 Generated with Claude Code

[sym-bot]

Reviewed against main 2026-08-12: not superseded — main still records refusals under the constant 'bad-signature' (lib/frame-handler.js:418) while verifyCMB distinguishes four reasons. Checks pass on the branch. Needs rebase across the room rename, then mergeable. Keep open.