feat(queen): record what accepted .t27 work has earned, append-only

[gHashTag]

Why

Owner's goal (2026-10-01): people who write .t27 specs mine TRI for the specs the Queen accepts, and later sell it as a TON jetton. Nothing can be minted from a number nobody wrote down, so this PR adds the record. It is phase 1 of the plan in gHashTag/trinity-fpga#801 (docs/docs/depin/decisions.md). No token is involved, and nothing here is withdrawable.

What

• queen_tri_earnings (in MIGRATION_SQL) is append-only:
  • One row per (repository, issue, judged commit) the Queen accepted, where the turn's boundary declared a .t27 file.
  • work_id = sha256('t27-accept:v1|<repo>|<issue>|<commit>'). Anyone can recompute it from public data, which is what work_id in the mint protocol needs.
  • There is no amount column. TRI per spec is an owner decision (O2) and is not decided.
• recordEarnings(pool, repo) runs every round, after the CI take-back:
  • It is idempotent.
  • A later sendBack/escalate of the same commit revokes the earning, and the revocation is final. A fresh accept of the same commit does not bring it back. A new commit accepted after a send-back is a new earning.
• GET /queen/public-earnings is public-read on the same terms as the leaderboard:
  • It returns earners (grouped through TRIOS_KEY_OWNERS), totals, and the last 100 earnings.
  • It never includes an issue title, worker text, review note or credential.
  • Its body says "recorded, not withdrawable: no token is deployed" and triPerSpec: null, and lists what is not yet true:
    • an accept does not require a merge (O4);
    • spec paths are declared, not yet checked against the diff;
    • TRI per spec is undecided.

Why a table rather than derive-on-read like the leaderboard

A CI take-back edits queen_dispatch in place (queen-ci-verdict.ts). If earnings were derived on read, an acceptance that was later taken back would disappear. Here it stays, with revoked_at beside it.

Tests

• tests/api/queen-tri-earnings.test.ts (unit):
  • grouping and ranking;
  • query parameters, ON CONFLICT DO NOTHING, and the "only a later verdict revokes" guard;
  • the "no amount, not withdrawable" wording;
  • a 503 without a database.
• tests/pglive/queen-tri-earnings-live.test.ts runs against a real PostgreSQL (scratch DB, same rules as the migration gate: fails rather than skips unless TRIOS_PG_MIGRATE_GATE=offline). It checks:
  • the same commit accepted twice is recorded once, dated by the first acceptance;
  • a non-.t27 accept is excluded;
  • work_id equals a sha256 computed in Node;
  • a send-back before the acceptance does not revoke it;
  • a take-back revokes, a re-accept does not resurrect, and a new commit earns.
• Route-guard census re-measured: 46 mounts, 9 public-read, 23 /queen mounts. Prefix and wrapper counts are unchanged.

Run locally:

• bun test on the four touched suites: 44 pass.
• bun run test:pglive: 4 pass, against local PG 17.
• tsc --noEmit: 0 errors.
• biome check: clean. The one existing complexity warning in queen-tick.ts was already there.

Not in this PR

• The amount (O2), the merge requirement (O4), and diff-checking the spec paths.
• The attestor service and any minting. Those stay blocked on owner decisions O1–O6.
• The website panel that reads this route will come in a separate PR in gHashTag/trinity.

Base and CI

• Base is now fix/queen-worker-provider-and-prompt-size. That is the branch Railway deploys Queen from, so merging this PR ships the route.
• This branch merges fix(ci): pin Bun to the workspace version and untrack a local node_modules symlink #520 (Bun pin in test.yml, untracks the apps/server/node_modules symlink to /Users/playom/...). Without it, bun ci hangs for about 20 minutes and gets cancelled. Merge fix(ci): pin Bun to the workspace version and untrack a local node_modules symlink #520 first; after that, this PR's diff is only its own files.
• earningsOfLogin now types its base object as Omit<EarningsOfLogin, 'earnings'>, so status stays the literal type. That was the one typecheck error.
• Route-guard pins count both new mounts: 47 total, 24 under /queen (9 public-read, 8 wrapper-guarded, 7 allowlisted).

🤖 Generated with Claude Code

[github-actions]

✅ Tests passed — 2450/2510

Suite	Passed	Failed	Skipped
✅ agent	87/87	0	0
✅ build	9/9	0	0
✅ cdp-protocol	5/5	0	0
✅ eval	93/93	0	0
✅ server-agent	272/272	0	0
✅ server-api	1319/1378	0	59
✅ server-browser	6/6	0	0
✅ server-integration	10/11	0	1
✅ server-lib	279/279	0	0
✅ server-pglive	13/13	0	0
✅ server-root	68/68	0	0
✅ server-skills	31/31	0	0
✅ server-tools	244/244	0	0
✅ shared	14/14	0	0

View workflow run

[gHashTag]

Reviewer bee: I reviewed the code and found no blocking issues. Tests / * and PR test summary are green, and the pglive earnings test ran against a real Postgres. I merged #520 first as a squash (29ed593). After that, GitHub marks this PR CONFLICTING/DIRTY against fix/queen-worker-provider-and-prompt-size. The likely cause is that this branch carries #520's original commits while the base now has the squashed copy, so the shared edits collide, most likely in tests/api/routes/route-guard.test.ts, where #520 pins 46/23 and this PR pins 47/24. I have not resolved it and have not merged. The author needs to merge the base in, keep this PR's numbers (47 total, 24 /queen: 9 public-read, 8 wrapper, 7 allowlisted), and push. Once CI is green again I will merge.

Non-blocking notes from the review:

• earningsLedger reads the whole queen_tri_earnings table on every public GET. Only recent is capped at 100, and /by/:github is uncapped. The table grows only with accepted spec turns, so this is fine for now. If it grows, consider SQL aggregates for the totals and earners plus a LIMIT.
• Each public request opens and closes its own pg pool (max 1). That is better than the leaderboard, which never closes its pool, but every uncached hit still costs a fresh DB connection.