docs: update Arc Testnet version to v0.7.3 in installation.md

[Sertug17]

Summary

The Versions table in docs/installation.md listed v0.6.0 as the required version for Arc Testnet. The current release is v0.7.3.

Problem

A node operator following the installation guide would install v0.6.0, which can no longer sync with Arc Testnet. Per BREAKING_CHANGES.md:

"testnet node operators must use v0.7.2 before timestamp 1781791200 (2026-06-18 14:00:00 UTC), when Zero7 activates on testnet. Earlier versions are not supported."

That deadline has passed — v0.6.0 nodes are incompatible with the current testnet network.

Change

• docs/installation.md: Versions table updated from v0.6.0 → v0.7.3

Closes #225

[osr21]

The table change itself is correct — v0.7.3 is the latest release and the direction is exactly right. One change needed before this fully closes #225:

Line ~64 of the same file still reads arcup --install v0.6.0. As noted in #225, the "install a specific version" example carries the same stale tag, so with only the table updated the doc contradicts itself one section down — the table says v0.7.3, and the copy-pasteable command 45 lines later installs the version that can't sync. Since that snippet is the one operators actually paste into a terminal, it's arguably the more dangerous of the two references. A one-line addition to this PR (arcup --install v0.6.0 → arcup --install v0.7.3) covers it.

Two optional nits, take or leave:

• The PR body quotes the Zero7 deadline (2026-06-18), but v0.6.0 actually fell off at Zero5/Zero6 activation on 2026-05-27 per the v0.7.1 note in BREAKING_CHANGES.md — harmless in a PR description, just noting so the commit message doesn't understate how long the doc was stale.
• If you want to make this the last time the table drifts, a sentence under the table like "For fork-activation deadlines and the minimum supported version, see BREAKING_CHANGES.md" gives readers a self-updating source of truth even when the pinned tag lags. The structural fixes (link to releases/latest, or a release-checklist grep) can stay follow-up material — no reason to hold a one-line correction hostage to them.

Happy to re-review as soon as the --install example is updated; with that included this is a clean close of #225.

[Sertug17]

Thanks for the thorough review, @osr21! Good catch on the arcup --install example. I've pushed a second commit to update that line as well (now both the Versions table and the install example point to v0.7.3).

On the longer-term suggestion: agreed that a pinned version will drift again. Option (a) linking to the latest release page with a pointer to BREAKING_CHANGES.md seems like the lower-maintenance path. Happy to follow up with that in a separate PR if the maintainers prefer to keep this one focused on the immediate fix.

[osr21]

The second commit closes the gap — table and arcup --install example now both read v0.7.3, verified against the latest diff at 0bb5dfec. That's the full set of stale references in installation.md (the remaining v0.6.0 hits in the repo are quake version-compat test fixtures and CI workflow entries where the old tag is intentional), so this is now a complete close of #225. Approving.

Agree with keeping the anti-drift change as a separate PR — it has its own small design question (where to keep a pinned tag for reproducible source builds vs. where to defer to releases/latest), and this fix shouldn't wait on that discussion. The one-sentence pointer to BREAKING_CHANGES.md for fork deadlines would be a good inclusion in that follow-up, since it's the file that actually answers "is my version still viable" between doc updates.