the proposal join resolves handles numerically while the report keys them as strings so six spellings pass the gate green and admit nothing

the proposal join resolves handles numerically while the report keys them as strings so six spellings pass the gate green and admit nothing

Found by the round-3 security review. Pre-dates round 3 on the branch (the adm store's join landed in round 2); does not reproduce on main.

checkRecordJoins resolves the target NUMERICALLY (anyHandleFullRe + strconv.Atoi, schema.go:831-842) while admittedProposals keys it as a raw STRING (issueScalar, readingoutstanding.go:476,485). So six spellings pass the gate with ZERO findings and admit nothing, permanently and silently, probe- verified: "RDI-2608300000000002", "Rdi-…", "rdi-02608300000000002", "rdi-… " (trailing space inside the quotes), " rdi-…", and bare prose. The first three RESOLVE and match the bucket, so the gate actively approves them; the rest fall through the m == nil → continue "prose is legitimate" branch.

Meanwhile reading_outstanding goes on printing that the proposal has neither an admission nor a decline while the admission record sits in the tree. That is verbatim the harm iss-2608301327013320 (major) was opened and closed for: round 3 closed the CROSS-RUN spelling and left six.

The contrast is one leg away: the sibling run field is compared as a literal string (isAbsentValue(got) || got == r.bucket, schema.go:911) and catches every spelling tried against it.

Remedy, one place: a join that declares sameBucketAs is a join whose value the schema says must be a handle of that family, so for such a join a value that is not verbatim ^<family>-[0-9]+$ — no case shift, no leading zero, no padding surviving the quotes — is a finding rather than a continue. occasioned_by, which declares no family, keeps its prose tolerance untouched.