README: haf_stats disk footprint and sync-time data (refs #63)

Refs #63 (closed). This is the documentation half: the issue's first fix item. #63 (closed) stays open for its second item, a hivemind-parity guard that can run on a production node.

What it adds

A "Resource requirements" section in the README, before Quick Start. It was measured on 2026-10-23, read-only, on a full-history HAF 1.28.8 node (PostgreSQL 18.6) with haf_stats at head (block 111,019,709) and develop 4a43cf5 installed.

• Logical size: 254 GB (binary units, as pg_size_pretty prints them), all in haf_stats_backend (106 GB heap, 148 GB indexes).
• Largest tables:
  • active_users_daily 90 GB, 542 M rows;
  • account_custom_json_daily 78 GB, 561 M;
  • account_financial_daily 29 GB, 108 M;
  • comment_registry 28 GB, 133 M;
  • the other 30 tables 30 GB together.
• The other app schemas on the same node:
  • hivemind_app 558 GB;
  • haf_fyp_app 270 GB;
  • hafbe_bal 84 GB;
  • hafbe_app 80 GB;
  • hivesense_app 61 GB;
  • reptracker_app 27 GB.
• On-disk estimate: the database is 5.3 TiB logical and 2.6 TiB on that node's compressed ZFS dataset, about 2x for the database itself. If haf_stats compresses alike, it takes roughly 125 GB on disk.
• Growth: active_users_daily gained about 40,000 rows a day over the last 30 days, at about 180 bytes a row including indexes.
• Sync time, stated as what it is: no clean from-zero measurement exists.
  • The one data point is a catch-up on that node: block 77.05 M to head (about 34 M blocks) in about 36 h, an average of roughly 0.95 M blocks an hour. It ran on an 8-core box shared with every other app, partly during another app's index build. The figures are from the session that rebuilt the node.
  • The step-8 one-time backfills stay "unmeasured at mainnet scale", as install_app.sh already says.

The 354 GB that #63 (closed) quotes (2026-09-04, another install) is noted as superseded.

Review

This is a docs-only change, so it got one fact-checking reviewer. It re-derived every figure on the same node:

• the sizes, row counts, growth rate, PostgreSQL version and block all held;
• it found three errors: a wrong average sync rate (1.1 M/h should be about 0.95 M/h), mixed decimal and binary units in the TB figures, and the dataset compression ratio (2.19x) used where the database's own (about 2.03x) applies. That ratio error put the on-disk estimate at 115 GB instead of about 125 GB.

All three are fixed in the second commit.