content(play): publish a player-first Classic getting-started path

[zoeyrose]

Outcome

Publish a durable /play/ journey that helps a prospective player move from the website to a correctly installed Atrinik Classic client, understand current connection availability, and know what to do next without reading developer documentation.

/downloads/ remains the immutable artifact and license-evidence page. /play/ owns the player-facing onboarding journey.

Why

The site currently establishes that Classic is playable and exposes a verified download, but it does not explain the end-to-end player path. The archived installing and how-to-play URLs consequently redirect to /downloads/, where release evidence is available but ordinary onboarding is not.

A focused play page fulfills part of the information architecture retained in #4, provides a useful destination for search and referral traffic, and reduces the gap between downloading a ZIP and successfully opening the game.

Scope

• Add a fully static /play/ route with a clear player-first heading, description, and primary action.
• Explain the supported Classic journey in plain language:
  • confirm the supported platform and architecture;
  • choose the exact verified client artifact from /downloads/;
  • extract the complete package without separating its files;
  • launch the packaged client;
  • understand the currently supported connection path and what is or is not publicly available.
• Reuse validated release metadata rather than duplicating mutable version, platform, protocol, artifact, checksum, or compatibility facts in prose.
• Revalidate public-service availability during implementation. Never infer availability from an old client default, advertise an unverified server, or imply that account creation/connection succeeds when it does not.
• Render an honest static unavailable or pending state when no supported public service exists, including useful actions a visitor can take meanwhile.
• Keep advanced configuration, source builds, server administration, protocol details, and contributor instructions in their owning repositories; link to authoritative material where useful.
• Keep Classic and the incomplete next-generation foundations visibly distinct.
• Link the page from the homepage, downloads journey, and appropriate shared navigation/footer locations.
• Remap /page/installing_atrinik_client* and /page/how_to_play* to /play/. Leave starter/player-guide redirects for the dedicated first-hour guide.
• Add the page to the sitemap and provide page-specific title, description, canonical URL, semantic structure, and accessible instructions.
• Use static Astro/HTML/CSS only. Do not add accounts, credentials, forms, browser JavaScript, live status calls, a server runtime, or a database.
• If media is introduced, satisfy the complete media provenance, license, digest, transformation, attribution, and accessible-alternative contract.

Acceptance criteria

• /play/ gives a new player a coherent path from the verified download to launching Classic, with no developer-documentation prerequisite.
• Version, platform, artifact, and compatibility details come from the validated download catalog or link to it; contradictory duplicate facts are not introduced.
• Public server/account availability is freshly verified and represented honestly, including a useful unavailable state.
• No unsupported platform, next-generation download, public server, or successful connection is promised.
• The homepage and downloads journey link clearly to /play/.
• The two relevant archived routes redirect permanently to /play/ without a redirect chain.
• The sitemap and internal-link validation include the new canonical page.
• The page works with keyboard-only input, representative screen-reader navigation, narrow/desktop layouts, reduced motion, and no JavaScript.
• The built output retains zero repository-authored JavaScript and passes the established security, accessibility, provenance, and performance budgets.
• npm run check, npm run build, npm run deploy:dry-run, and git diff --check pass.

Dependencies and coordination

• This is a focused delivery slice of Relaunch atrinik.org from the standalone MIT website repository #4 and should align its player language with content(home): lead with a player-first Atrinik Classic pitch #26 and metadata contract with feat(metadata): add structured identity, favicons, and page-specific previews #27.
• Coordinate gameplay or instructional imagery with content(media): replace temporary generated concept art with human-created visuals #22. That issue is not a hard dependency: an honest typography/CSS presentation is preferable to unproven media.
• The generated-file cap must accommodate the route or be adjusted deliberately with corresponding architecture and validation documentation; aggregate byte and zero-JavaScript budgets must not be weakened.
• A public game service is not required to publish the page, but it is required before the page may claim that visitors can connect or create an account.