Publish a measured CPU/RAM/disk sizing table for gittensory-miner laptop-mode vs fleet-mode

[JSONbored]

Context

Neither the existing operational-runbook issue (#4875) nor the local-stores documentation issue (#4870) commits to publishing real, measured resource numbers for running the miner — both are scoped to narrative/reference content, not a sizing table. Operators currently have no data-backed answer to "how much CPU/RAM/disk does one laptop-mode run need, and how does that scale in fleet mode?"

Dependencies

None — independently shippable. It is easiest to measure fleet-mode numbers using the docker-compose.miner.yml sibling issue in this batch if that has already landed, but this issue can also measure via a manual docker run --scale-style setup if it lands first — it is not blocked either way.

Requirements

1. Run a single laptop-mode gittensory-miner discover/attempt cycle locally and record peak CPU, RAM, and disk usage during a representative run.
2. Run a fleet-mode N-worker container setup (via docker-compose.miner.yml if available, or an equivalent manual multi-container setup) and record peak CPU/RAM/disk for at least two worker-count configurations (e.g. N=1 and N=4).
3. Present the measured numbers as a table — either a new doc (e.g. packages/gittensory-miner/docs/sizing.md) or a dedicated table within DEPLOYMENT.md — with columns for mode, worker count, CPU, RAM, disk, and the measurement environment (hardware/OS, since laptop numbers vary by machine).
4. Record and document the measurement methodology used (e.g. docker stats, /usr/bin/time -v, or an equivalent tool) so the numbers are reproducible and falsifiable, not asserted from memory.
5. Scope this deliverable strictly to the sizing table — do not fold in broader operational-runbook content; that belongs to the separate runbook issue (Write an operational runbook #4875).

Deliverables / Acceptance Criteria

• Laptop-mode CPU/RAM/disk numbers measured and recorded
• Fleet-mode numbers measured for at least two worker-count configurations
• Sizing table published (new doc or DEPLOYMENT.md section) with mode/workers/CPU/RAM/disk/environment columns
• Measurement methodology documented so numbers are reproducible
• No unrelated runbook content added in this PR

Test Coverage Requirements

This PR must ship with full test coverage for every changed line and branch — the repo's Codecov patch gate requires 99%+ coverage and the house standard is to aim for 100%, including both sides of every conditional/nullish-coalescing branch introduced. This issue is a docs-only deliverable with no src/** logic change, so the standard Codecov patch gate does not apply to the published numbers themselves; however, if any measurement script or helper is added to produce the numbers, that script must ship with (1) unit tests covering its success and failure paths (e.g. metrics tool present vs. missing), (2) an invariant test asserting the script never fabricates or interpolates a number it didn't actually measure (it should error rather than silently substitute a placeholder), and (3) not applicable as a bug-fix regression test since this is net-new documentation, not a fix. The PR description itself must include the exact commands/environment used so a reviewer can independently re-run and verify the published numbers.

Expected Outcome

An operator deciding between laptop-mode and fleet-mode (and how many fleet workers to run) can size their host or cluster from real numbers instead of guessing.

Links & Resources

• DEPLOYMENT.md — where the sizing table may live
• docker-compose.miner.yml sibling issue in this batch — fleet-mode measurement environment
• Write an operational runbook #4875 (operational runbook) and Update DEPLOYMENT.md to document all local stores #4870 (local-stores documentation) — related but explicitly out of scope for this issue
• Theme: Self-host packaging & docs

[linear-code]

JSO-3719