docs: fix testnet version pins and eth_blockNumber verification wording

[kutluhaneth46]

Summary

Operator documentation fixes — three stale or incorrect items that mislead node runners:

1. installation.md — Arc Testnet version table and arcup example still pointed at v0.6.0; updated to v0.8.0 (current release; Zero8 activates on testnet 2026-09-03 per CHANGELOG).
2. running-an-arc-node.md — "Verify operation" claimed eth_blockNumber returns the next block height and documented a broken printf "%0d" conversion; aligned with the Docker verify section and osr21's guidance on docs: node verification guide incorrectly describes eth_blockNumber as returning the next block height #272.
3. docker-compose.yml — header comment examples updated from 0.6.0 to 0.8.0.

Fixes #272, #225, #235.

Validation

• Docs-only change
• Wording matches Docker "Verify" section for eth_blockNumber
• Version matches CHANGELOG v0.8.0

Test plan

• Version table and arcup example consistent
• Bare-metal verify prose matches Docker verify section
• docker-compose comment examples match current release tag

[osr21]

Verified all three content changes against the repo, CHANGELOG, and live behavior — the substance is correct, and one part is genuinely time-critical. But the PR overlaps two open PRs, one of them already approved, and would benefit from dropping one hunk.

Content verification

• eth_blockNumber wording — correct fix, matching what was confirmed on docs: node verification guide incorrectly describes eth_blockNumber as returning the next block height #272: the RPC returns the latest block known to the node, not the next height. The new sentence also aligns the bare-metal section with the Docker verify section's semantics. ✔️
• Version pins — v0.8.0 is right, and the timing matters more than the PR body says: per CHANGELOG.md, testnet operators must run a Zero8-capable version before timestamp 1788447600 — 2026-09-03 15:00 UTC, tomorrow. After that, the table's v0.6.0 isn't just stale (it already couldn't follow testnet since Zero5/Zero6 on 2026-05-27, per the docs: Versions table in installation.md still lists v0.6.0 for Arc Testnet (current: v0.7.3) #225 thread); every pre-Zero8 version becomes unsupported. Both stale spots flagged on docs: Versions table in installation.md still lists v0.6.0 for Arc Testnet (current: v0.7.3) #225 are covered here (the table and the arcup --install example at line ~64). ✔️
• printf framing, one precision note — printf "%0d" isn't strictly broken: given the hex as an argument it converts fine in bash and POSIX sh builtins (printf "%0d" 0x10 → 16; the 0 flag with no width is a no-op). The real defects in the old line were the "next block height" semantics and that no argument syntax was shown at all. Your replacement printf "%d\n" <hex> is strictly better either way — this is framing, not a requested change.

Overlaps (the actionable part)

1. deployments/docker-compose.yml hunk conflicts with approved docs: use $ARC_VERSION in docker-compose.yml image comments #238 — merge-tested in both orders: textual conflict both ways, since both PRs rewrite the same two header-comment lines. docs: use $ARC_VERSION in docker-compose.yml image comments #238 (open since early August, approved) implements the $ARC_VERSION pattern that the docs: docker-compose.yml comment examples still reference v0.6.0 #235 discussion deliberately chose over a literal pin, precisely so these comments stop going stale each release. This PR's literal 0.8.0 re-introduces the drift cycle — the same one that let the installation table sit wrong through three releases. Suggest dropping the docker-compose hunk from this PR and letting docs: use $ARC_VERSION in docker-compose.yml image comments #238 close out docs: docker-compose.yml comment examples still reference v0.6.0 #235.
2. docs/installation.md lines are the same two lines open docs: update Arc Testnet version to v0.7.3 in installation.md #226 edits (to v0.7.3, itself now stale). This PR supersedes docs: update Arc Testnet version to v0.7.3 in installation.md #226 on both counts; flagging so maintainers close one, or whichever lands second hits a conflict.
3. No conflict with docs: mark separated-host RPC transport deprecated as of v0.8.0 #295 — merge-tested clean; the two PRs touch running-an-arc-node.md ~170 lines apart. No coordination needed there.

Slimmed to installation.md + running-an-arc-node.md, this lands two verified fixes (#272, #225) with no competing PR — and the version-table half is the one with a hard deadline tomorrow.

[kutluhaneth46]

Dropped the \deployments/docker-compose.yml\ hunk in fb6e7b9 — leaving that to approved #238 as you suggested. PR now only touches \installation.md\ +
unning-an-arc-node.md\ (#272, #225).

[osr21]

Verified fb6e7b9 — the PR now touches only docs/installation.md and docs/running-an-arc-node.md, and deployments/docker-compose.yml is untouched (still at 0.6.0 on this branch, correctly left to #238).

Re-ran the merge tests against current main:

Combination	Before	Now
#306 + #238	conflict, both orders	clean, both orders ✔️
#306 + #295	clean	clean ✔️
#306 + #226	conflict	still conflicts (docs/installation.md)

So the only remaining overlap is #226 — and while digging into the CHANGELOG for that, I found an argument that makes closing it more clear-cut than "it's stale":

#226's v0.7.3 pin doesn't just lag — it becomes wrong at the deadline. Zero8 shipped dormant in v0.7.3 ("Add the Zero8 hardfork (dormant) … not scheduled on any public chain"), so it's tempting to read v0.7.3 as "a version supporting Zero8". But v0.8.0 adds [EL] Gate corrected EIP-161 deletion of synthetic empty accounts behind Zero8, preserving historical pre-Zero8 state roots — a state-root-affecting behavior keyed to Zero8 activation. A v0.7.3 node carries the dormant fork definition without that gating, so at activation it diverges rather than simply refusing to start. v0.8.0 is the correct pin, and #226 would ship a value that's actively wrong ~29 hours from now.

Timing, for whoever picks this up: Zero8 activates on testnet at 1788447600 — 2026-09-03 15:00 UTC, about 29 hours from this comment. This PR is the only open change that puts a Zero8-capable version in front of an operator following the install guide.

One non-blocking nit on the other half: the new line uses a placeholder — printf "%d\n" <hex>. Since the preceding block is a copy-pasteable curl, a concrete round-trip (e.g. printf "%d\n" 0x3941a0c) would save readers guessing whether <hex> includes the 0x prefix and the quotes. Purely cosmetic; the semantics fix — which is the part #272 was actually about — reads correctly as-is.

Nothing else outstanding from my side on this PR.