The forge reports npm registry bytes per hour, so the steward can see the bun cache working #7546

Intent: #7541 was found with btop and a packet capture. The forge's own egress tally should show the same thing, so a regression shows up without either.

Done when:

• [ ] The egress tally (src/apps/egress.ts, src/apps/egress_metrics.ts) keeps cumulative bytes per destination, not only bytes over open connections. /metrics exposes them as counters, e.g. forge_egress_bytes_in_total{destination="registry.npmjs.org:443"}.
• [ ] Each install step logs one line with the registry bytes it fetched ("install fetched 0 B from the registry" on a warm cache), measured from the egress tally for that cell or from the cache's growth.
• [ ] A read the steward can call (an MCP tool's field or the flow report, whichever already carries capacity figures) answers npm bytes over the last hour. Tests cover the counter and the hourly figure.
• [ ] The README or docs/ says where to read it.

Files: src/apps/egress.ts, src/apps/egress_metrics.ts, src/checks/service.ts (the log line), the chosen MCP or flow surface, tests.

Risks: cumulative counters must not grow without bound per run label. Key them by destination, or reset them hourly.

Brief: a builder who knows the egress proxy and the MCP.

Parked by the crew: the check failed ("bytes add up per destination across labels") and the decider saw no point in another try try 1: README.md, docs/APPS.md, docs/CLI.md, docs/CREW.md (+264 more) (pull #7565 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.