auth_events: record the reporting principal, and distinguish direct from unrecorded

[iceteaSA]

Closes the gap in #42. auth_events already had principal_kind and principal_id; the read surface never filled them, so every consumer-report row in both our stores is NULL.

The three states, which is the actual ask

route-bound caller   principal_kind='reserved'  principal_id='prefrontal-core'
direct caller        principal_kind='direct'    principal_id=NULL
pre-change row       principal_kind=NULL        principal_id=NULL

A direct caller genuinely has no name — that is an answer, not a gap. Before this, it rendered identically to "we did not record", so an absent principal meant nothing and could not be read as evidence either way.

AuthEventPrincipal is typed, following reporter_source's shape, so a raw consumer string remains unrepresentable at the call site rather than merely rejected.

Mutations

Two from the implementer, one I ran myself because it targets the design point rather than the plumbing:

Some(Principal::Direct) => None      // collapse state 2 into state 3
  -> FAIL consumer_reports_preserve_route_direct_and_legacy_principal_states
     main.rs:2332  left: None  right: Some("direct")
restored byte-identically, green

One correction to the commit as returned

The floor was left at 621 while the tree measured 622. Both the gate (622 >= 621) and the ratchet (621 >= master's 621) passed, so nothing went red — and the new test was unprotected: delete it later and the gate still passes. That is precisely the defect the floor exists to catch, sitting inside the change that added the test. Floor set to the measured 622, red-checked (623 fails, 622 passes).

Worth noting because a floor that is merely not lowered is not the same as a floor that is correct, and only the first of those is mechanically enforced.

A red gate I chased and a claim I withdrew

Two full-gate runs failed on manifest_lock_aba_regression members — different members each time (:1449, then :1334) — in a file my diff touches zero lines of. The fixtures use Duration::from_millis(100) TTLs, so real elapsed time crosses them when the machine is busy.

I then measured master passing a full gate while mine failed twice, and started writing that up as a branch-caused regression with a plausible mechanism (my new async test adds parallel work, lengthening wall time inside those 100ms windows). Run 3 on my branch passed, which kills it. The load differed across the comparison because I was generating the load myself with back-to-back gate runs — master ran at 2.4, mine at 3.9. That is not a branch measurement, and I withdraw it.

Third sighting of this class. #33 fixed one member by converting the race to arithmetic (making the work outlast the TTL by construction); these are the survivors. Filing separately rather than widening this PR.

Verification

bash scripts/gate.sh exit 0, workspace floor 622 >= origin/master 621 at e97bc73, Cargo.lock unchanged, one commit over master.

No migration — the columns already existed.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

---

Summary by cubic

Fills the principal_kind and principal_id columns in auth_events, which the read surface never populated, so every consumer-report row was NULL. Route-bound reports now record reserved with the module id, direct callers record direct with no id, and pre-change rows stay NULL — so a direct caller reads as an answer, not a gap.

Notes

• report_auth_failure now accepts the principal and records it through the new typed AuthEventPrincipal, so raw consumer strings can't be written at the call site.
• Bumps the gate floor from 621 to 622 to cover the new test.
• No migration needed; the columns already existed.

^{Written for commit 9c82d31. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 7 files

_{You’re at about 95% of the monthly reviewed-line limit. You may want to disable incremental reviews to conserve quota. Reviews will continue until that limit is exceeded. If you need help avoiding interruptions, please contact contact@cubic.dev.}

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="scripts/gate.sh">

<violation number="1" location="scripts/gate.sh:356">
P3: The new floor contradicts the gate’s documented measured total: the comments say 614, while `run_expect` now enforces 622. Update the nearby measurement commentary to the verified 622 count so future floor changes are based on one consistent value.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The new floor contradicts the gate’s documented measured total: the comments say 614, while run_expect now enforces 622. Update the nearby measurement commentary to the verified 622 count so future floor changes are based on one consistent value.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At scripts/gate.sh, line 356:

<comment>The new floor contradicts the gate’s documented measured total: the comments say 614, while `run_expect` now enforces 622. Update the nearby measurement commentary to the verified 622 count so future floor changes are based on one consistent value.</comment>

<file context>
@@ -353,7 +353,7 @@ assert_floor_not_lowered() {
 # THE FLOOR IS RATCHETED AGAINST THE MERGE TARGET BY `assert_floor_not_lowered` BELOW,
 # because a floor alone does not defend the property it exists for. See that function.
-run_expect 621 "workspace unit + integration" \
+run_expect 622 "workspace unit + integration" \
   cargo test --locked --workspace --features credentials-core/test-support
 
</file context>