fix(hub): export public identity in up runbook

[dp-web4]

Closes #779.

hub up now prints the resolved export-public-identity command before serve, so a first public hub exports the identity its locked surface and unlock require. The Quickstart and Hub README now describe that same sequence.

RWOA+S+V: this changes operator guidance only; it does not export anything automatically. The export is an intentional, reversible public-identity publication step. A regression test pins the resolved command spelling and its order before serve.

Verification: focused hub-daemon regression passed (1 passed); staged diff was whitespace-clean; upstream impact analysis was low risk with one direct caller (main).

[dp-web4]

APPROVED: hub-track, merging.

Reviewed against head cd908996; standing-blocks CLEAR (pr_standing_blocks.py web4 788, rc=0).

Scope matches description. Extracts the hub up go-live printer into go_live_runbook(), inserts export-public-identity before serve, and reconciles QUICKSTART/README to the new runbook. No creep.

The refactor is behaviour-preserving where it should be. The old code passed law_path to the set-law step; the new renderer computes hub_dir.join("hub-law.yaml"), which is the same value — law_path is defined at main.rs:1102 as exactly that join. So the extraction does not silently change the printed path, which was the one place a params-vs-recompute refactor could have drifted.

One behaviour change, and it is a fix. Previously serve was printed as an unnumbered continuation line (5-space indent) under the env-load step, and unlock reused the already-incremented n — so the runbook's numbering skipped over its own serve step. It is now numbered in sequence. Worth naming explicitly since the PR body does not.

The new guard was run against what it guards. Not just "the test passes" — I deleted the export line from the renderer in an isolated worktree and re-ran: rc=101, hub_up_runbook_exports_public_identity_before_serving ... FAILED with runbook must export the public identity. The assertion bites on the property it claims, including the ordering leg.

Full suite green on this SHA, built in a separate CARGO_TARGET_DIR (never the live daemon's ExecStart path): cargo test -p hub-lib -p hub-daemon rc=0 — 187 + 328 + 3 + 4 + 6 = 528 passed, 0 failed.

Doc sweep, because establishing a fact is not applying it. The stale claim is QUICKSTART:39 ("One step hub up's printed runbook does not list") and this PR is what removes it. Re-grepped the other two docs that mention the subcommand — HESTIA-MODE.md:183 (command reference) and TROUBLESHOOTING.md:144 (recovery step) — both are independent of hub up and remain correct. Nothing else in hub/ still asserts the omission.

RWOA: operator guidance only; the export stays an explicit human step, nothing is published automatically.