kanon-lint CI check is a no-op stub; 5 pre-existing warnings pass unenforced

[forkwright]

Finding

The kanon-lint job in .github/workflows/ci.yml always exits 0 on hosted runners, so it never actually enforces anything — and the local full-tier gate (kanon gate --tier full, which runs the real check) currently fails on 5 pre-existing warnings that have been silently passing PR after PR.

Evidence

• kanon-lint's CI job depends on FLEET_REPO_TOKEN, which is unset on GitHub-hosted runners for this repo — the job echoes a warning and exits 0 regardless of findings (confirmed by PR fix(rate-limit): verify peer before honoring X-Forwarded-For #103's adversarial reviewer while checking a different claim, and reconfirmed 2026-08-16 running kanon lint . --all and a real kanon gate --tier full on verda-build against fix/67-trusted-proxy-extractor merged with main @ 9c56500).
• The full local gate's kanon lint step fails (0 errors, 6 warnings — full tier requires zero) while kanon-lint's GitHub Actions check reports green on the same commit.
• The 6 warnings, one already tracked:
  • .github/workflows/gate-attestation.yml:1 [YAML/missing-concurrency] — workflow missing a concurrency group.
  • .github/workflows/gate-attestation.yml:81 [SHELL/unpinned-action] — forkwright/.github action not pinned to a SHA.
  • Cargo.toml:8 [WRITING/identity-fluff] — identity-fluff word in the package description.
  • README.md:3 [WRITING/identity-fluff] — identity-fluff word in the opening line.
  • src/store.rs:1 [RUST/file-too-long] — 889 lines, limit 800.
  • tests/consent_contract.rs:1 [RUST/file-too-long] — 841 lines, limit 800 — already tracked as tests/consent_contract.rs exceeds the 800-line file-too-long limit #102, not part of this issue's scope.

Why this matters

A gate that always passes isn't a gate — it's a green checkmark that means nothing. Every PR merged since FLEET_REPO_TOKEN went missing from the hosted runner has had zero real lint enforcement, and the 5 warnings above (plus #102's) are the accumulated result. The next PR that pushes store.rs over its limit, or adds an unpinned action, will look identical in CI to one that didn't.

Desired correction

1. Fix the CI job so it fails hosted runs instead of silently exiting 0 when it can't reach whatever FLEET_REPO_TOKEN gates — either provision the token for hosted runners or make the job itself, not just its findings, fail closed on the missing-credential path.
2. Clear the 5 warnings above (excluding tests/consent_contract.rs, tracked separately): add a concurrency group to gate-attestation.yml, pin the forkwright/.github action to a SHA, reword the Cargo.toml description and README.md opening line off the identity-fluff word, split src/store.rs under 800 lines.

Done when: kanon-lint's GitHub Actions check fails on a genuinely-broken commit (not just a rerun of today's), and kanon lint . --all / kanon gate --tier full report 0 warnings outside of #102's tracked scope.

[forkwright]

Re-scoping this issue after PR #109.

#109 closes the lying half of this issue's Done-when: kanon-lint's hosted job no longer reports SUCCESS having linted nothing. When FLEET_REPO_TOKEN is absent (true on this repo's hosted runners today), the job now reports GitHub's own SKIPPED status instead of a green check produced by a ::warning::-then-exit-0 fallback step. PR #109 also clears all 4 of the pre-existing warnings this issue named that were still open (gate-attestation.yml unpinned action + missing-concurrency, Cargo.toml/README.md identity-fluff); the 5th (src/store.rs file-too-long) was resolved separately by #110.

Still open and unmet: this issue's literal Done-when — "kanon-lint's GitHub Actions check fails on a genuinely-broken commit" — cannot be satisfied while FLEET_REPO_TOKEN does not exist on hosted runners, because SKIP is the only outcome the job can ever produce, for any commit, broken or clean. #109 deliberately does not claim to close this issue (Refs #107, not Closes) for exactly that reason — a permanent green-by-omission would be a second copy of the original defect with different paint.

Scoping this issue going forward to just that remainder. Two remediations, both already named in ci.yml's WHY comment on the kanon-lint job (added by #109):

1. Provision FLEET_REPO_TOKEN for forkwright/epistole's hosted runners (it gates checkout of the two private cross-repo dependencies, forkwright/kanon and forkwright/logismos).
2. Or: a public kanon binary install path (release artifact / public registry) that needs no cross-repo checkout at all, removing the token dependency entirely rather than provisioning around it.

Done when: kanon-lint's GitHub Actions check on this repo's hosted runners actually runs kanon lint . --summary (not SKIPPED) and can be observed failing on a commit seeded with a real lint violation.