An admin's "All fine" in tests reads only its own forge: the asks, board and capacity suites stop failing on signals their shard neighbours raise #1614

Eight parked pulls (#1405, #1542, #1486, #1503, #1527, #1581, #1558, #1531) went red on tests their change never touched. Most failed on the asks page > when nothing asks, it says All fine, and so does the header (test/asks.test.ts:89). The rest failed on the board's forge strip (test/board.test.ts), the Capacity note (test/capacity.test.ts) and the map (test/map.test.ts). For a site admin, askCountFor (src/web/studio/asks.ts) adds forgeNeeds (src/actions/health.ts), and forgeNeeds reads vitals(). The vitals depend on process-wide error and refusal counters, which another suite in the same shard can move.

Done looks like

• [ ] Two forges made by createApp in one process do not share the counters that vitals() turns into needs. Each forge keeps its own, or the counters are keyed per app. Production behaviour does not change.
• [ ] A test proves it: raising an error or refusal signal on one forge leaves another forge's admin seeing All fine on / and in the header.
• [ ] test/asks.test.ts, test/board.test.ts, test/capacity.test.ts and test/map.test.ts pass 10 runs in a row with their shard neighbours in the gate's order (scripts/gate.ts). The pull says how this was run.
• [ ] No assertion is weakened. A test changes only if it was wrong, and the pull says which one.

Files: src/actions/health.ts, the vitals module it reads, test/. Risk: hiding a real production need. Keep the production signal path identical.