A test pins the forge's daily crew ceiling: no cap, under, exactly at, and which run carried spend across it #6706

test/ceiling.test.ts now pins the daily crew ceiling, and forgeCeiling treats only a positive number as a cap. The type check is clean, and the new test and test/account-ceiling-reserve.test.ts pass. I didn't run the rest of the suite; the forge's check does that on push.

• forgeCeiling: before, a crewCeilingUsd of 0 came back as 0, which made ceilingReached true at any spend. Now 0, a negative, NaN or a missing value all give null. main.ts and spendReport in heartbeat.ts already treated them that way, so this brings the module in line with them. The doc comment says 0 means no cap rather than "no crew".
• ceilingReached: the test checks it is true at exactly the cap and above it, false just under, and false with no cap.
• ceilingHitAt: the test names the run that carried the sum across the cap, including one that lands exactly on it. It is null while under the cap or with no cap. Yesterday's runs, deploy and check runs (the non-agent ones) and null costs don't count. Runs are summed in time order whatever order they were inserted in.
• Same millisecond: one test inserts two runs with the same timestamp in an order that differs from their ids, plus a later one. The function returns only the run's created_at, so rowid order inside one millisecond can't change the answer. The test pins the sum and the boundary with the later run, not the rowid tie-break itself.

The run table in the test is a minimal one I created in memory, so a null cost can be inserted. The real table has a NOT NULL default for cost_usd.

Closes #6700

test/ceiling.test.ts now pins the daily crew ceiling, and forgeCeiling treats only a positive number as a cap. The type check is clean, and the new test and test/account-ceiling-reserve.test.ts pass. I didn't run the rest of the suite; the forge's check does that on push.

• forgeCeiling: before, a crewCeilingUsd of 0 came back as 0, which made ceilingReached true at any spend. Now 0, a negative, NaN or a missing value all give null. main.ts and spendReport in heartbeat.ts already treated them that way, so this brings the module in line with them. The doc comment says 0 means no cap rather than "no crew".
• ceilingReached: the test checks it is true at exactly the cap and above it, false just under, and false with no cap.
• ceilingHitAt: the test names the run that carried the sum across the cap, including one that lands exactly on it. It is null while under the cap or with no cap. Yesterday's runs, deploy and check runs (the non-agent ones) and null costs don't count. Runs are summed in time order whatever order they were inserted in.
• Same millisecond: one test inserts two runs with the same timestamp in an order that differs from their ids, plus a later one. The function returns only the run's created_at, so rowid order inside one millisecond can't change the answer. The test pins the sum and the boundary with the later run, not the rowid tie-break itself.

The run table in the test is a minimal one I created in memory, so a null cost can be inserted. The real table has a NOT NULL default for cost_usd.

Both of juniper's points are fixed and pushed. tsc --noEmit is clean, and test/ceiling.test.ts and the heartbeat and home suites pass. I didn't run the whole check.

• Same-millisecond test: juniper was right that it passed with ORDER BY created_at alone, because ceilingHitAt returns only created_at and both runs share it. I renamed it to "two runs in the same millisecond both count, and a later run follows them" and dropped the rowid claim. The rowid stays in the ORDER BY as a tie-break, but no test pins it.
• One rule for the cap: the remaining direct reads of crewCeilingUsd now go through forgeCeiling, so a cap of 0 means no cap everywhere.

- src/system/home_truth.ts and src/tui/screens/dashboard.ts (the alarmIdleCrew call) no longer read crewCeilingUsd ?? null. - dashboard.ts:121 was already routed through forgeCeiling. - I also routed spendReport in src/spawn/heartbeat.ts and the crew page's spending card in src/web/pages/crew.ts, which had the same check written out by hand.

I added no test for the new routing in home_truth.ts, dashboard.ts, heartbeat.ts or crew.ts. The existing suites still pass, but nothing there would fail if one of them went back to reading the raw value.