Docs/update arc testnet version and docker compose placeholders

[Lesnak1]

Summary

Fixes #238 and #225.

1. Updates docs/installation.md Versions table to list active Arc Testnet version v0.7.3 (previously v0.6.0), aligned with official GitHub API release data.
2. Replaces hardcoded 0.6.0 image tags in deployments/docker-compose.yml header comments with the ${ARC_VERSION} variable placeholder to align with docs/running-an-arc-node.md.

Rationale

Ensures node operators downloading pre-built binaries or Docker Compose specs target the correct current Arc Testnet release.

[osr21]

The content is factually right — I confirmed v0.7.3 is the latest release via the releases API, and per BREAKING_CHANGES.md the v0.6.0 table entry points operators at a version that can no longer sync testnet. But both halves of this PR duplicate open PRs that predate it, each filed by the person who reported the corresponding issue:

Half 1 — installation.md version table: already covered by #226 (Sertug17, Aug 5 — the author of issue #225, who said "happy to open a PR" and did). #226 is also a superset of this PR's half: it updates the Versions table and the arcup --install v0.6.0 example further down the same file, which this PR leaves stale at v0.6.0. That line matters — it's the copy-paste command operators actually run, so this PR's version of the fix would leave the document internally inconsistent (table says v0.7.3, install command says v0.6.0).

Half 2 — docker-compose.yml image-tag comments: already covered by #238 (teyrebaz33, Aug 8 — who also filed the underlying discussion issue #235). Same two lines, same substitution. One wording difference: #238 uses $ARC_VERSION and appends a pointer to the Versions table in installation.md, making the comment self-documenting about where the current value lives; this PR uses ${ARC_VERSION} bare.

A citation nit that compounds the picture: "Fixes #238 and #225" — #238 is not an issue, it's the PR this half duplicates. The underlying issue for the compose change is #235.

Since both prior PRs are open, mergeable, and each strictly equal-or-superset to the corresponding half here, the fair resolution is to let #226 and #238 land and close this one — first-come attribution matters for contributors who filed the issue and followed through with the fix. If either stalls or gets superseded, this PR becomes the natural fallback; watching #225/#235 is the way to catch that.

If you're looking for adjacent ground that's genuinely open: a sweep for other stale 0.6.0/version references outside these two files (e.g. any remaining literals in docs or scripts that neither #226 nor #238 touches) would be additive — that's exactly the recurring-staleness class issue #235 is about, and nobody has claimed a repo-wide pass.

[Lesnak1]

Thank you @osr21 for the detailed review and for confirming the technical validity of the v0.7.3 release update!

Totally agree with respecting first-come attribution for @Sertug17 (#226) and @teyrebaz33 (#238). I will close this PR to let their PRs land seamlessly.

Per your suggestion, I've opened a clean, additive PR covering remaining stale version references across docs/ and scripts/ to ensure complete internal consistency. Thanks again!

[osr21]

Clean close, and thanks for redirecting the effort rather than defending the duplicate — that's the right instinct.

I've reviewed #252 in detail there. Short version: the run-upgrade-test.sh hunk is good, but the crates/quake/README.md hunk should be reverted — that v0.6.0 is deliberately old (the paragraph explains how Quake downgrades CLI flags when pinning an older image, so replacing the example with the current release breaks the illustration). Details and a classification of the remaining 0.6.0 literals on main — stale vs. historical vs. arbitrary-example — in the review on #252.