Pacing decides from the provider's measured percent left, and concurrency goes back to its ceiling #8960

From #8873 and #8910. Done when:

• [ ] The weekly pacer uses the percent the provider reports (subscription_headroom) and the share of the week gone, not an inferred dollar cap; when no measurement exists it says so and holds, it never switches off silently.
• [ ] Its burn per hour is computed from successive measurements, so a meter that has not moved reads 0%/h.
• [ ] A test: a week that fell 8 points in 3 hours slows picks; a flat meter does not.
• [ ] crew.concurrency is back at its ceiling in forge.json/config; the pull says so.

Files: src/crew/ pacer module, a test.

Parked by the crew: the check stayed red through 2 automatic tries (pull #8983 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.

The weekly pacer now decides from the percent of the week the provider reports as used, against the share of the week's time gone. No dollar cap is inferred. I checked this branch again and pushed nothing, because the branch already held the work and was already on the forge. The gate, tsc --noEmit and the 70 tests in the 11 files this change touches all pass here. I did not run the full suite; the forge's check runs it on the push.

• Measured percent: the provider's reading is stored as subscription_measure, noted from the session's rate_limit_event. Pacing reads it through src/crew/week_read.ts, and src/core/measure.ts holds the new module. A migration, 20261103160000-subscription-measure, adds the storage.
• No measurement: if the provider has never reported, or its week has reset, the pace sentence says the pace is unknown. The crew then holds at a modest level; it is never switched off.
• Burn per hour: this is the fall of the reported percent between successive readings, so a meter that has not moved reads 0%/h.
• Tests: test/subscription-measure.test.ts covers a week that fell 8 points in 3 hours slowing picks and a flat meter not slowing them. test/runner-measure.test.ts covers the wiring from the session event. Other suites that care about pace now start from a measured quiet week, through test/helpers/week-quiet.ts.
• Concurrency: crew.concurrency is not lowered anywhere in the repository (forge.json doesn't set it), so the chart and capacity.ts defaults are the ceiling. Pacing is now what slows the crew. If a lowered value is still set at runtime in the live capacity table, it has to be cleared there; I can't reach that from here.
• Admin view: usage (the MCP tool and the usage page) shows each subscription's measured headroom. The terminal Usage screen, home and the dashboard print the same reading and pace sentence. docs/CREW.md has a new section, "The weekly pace reads the provider's measure (#8960)".

The earlier pull #8983 was closed after its check stayed red twice. I didn't see that log.

To try it, open the usage page as an admin, or call the MCP usage tool, and read each subscription's headroom line.

🤖 Generated with Claude Code

Parked by the crew: the run ended without a pull: no changes pushed: The weekly pacer now decides from the percent of the week the provider reports as used, against the share of the week's time gone. No dollar cap is inferred. I checked this branch again and pushed not

Parked twice since a person last spoke here, so it is the planner's now. Every reason:

1. the check stayed red through 2 automatic tries (pull #8983 closed)
2. the run ended without a pull: no changes pushed: The weekly pacer now decides from the percent of the week the provider reports as used, against the share of the week's time gone. No dollar cap is inferred. I checked this branch again and pushed not

The planner splits it, replaces it with a fresh issue, or defers it; a person can also say what to try. Nothing starts here until then, and the board lists it.

Already done on main in 8a8980d9 (#9002, same title): the pacer reads subscription_measure through src/crew/week_read.ts, burn per hour comes from successive readings, test/week-wiring.test.ts covers 8 points in 3 hours and a flat meter, and crew.concurrency is not lowered in the repository. If a lowered value is still set at runtime, clear it in Settings → Capacity. Closing as done.

replaced by #9049. The pacing work landed in 8a8980d9 (#9002). Only the runtime concurrency ceiling is left, and #9049 makes it visible and resettable.