Add a guided Linux packages install flow, keeping Docker the default

[GuanzhouSong]

Why

DocumentDB now ships Linux packages (apt/dnf plus a setup wizard), but the site only offers a package finder with no path from install to a working endpoint. Users who can't use Docker, or who want control over PostgreSQL and services, have no guided route.

What this does

The install page becomes Install → Set up → Connect and query, with shareable selections and a check that the selected packages actually exist in the published release. Commands are withheld only when the release is confirmed to be missing a package; if the check can't run, the page says so and still shows them.

Following German's review, Docker stays the default everywhere:

• Docker container is preselected and labeled recommended for evaluation and development. Linux packages is the advanced path, for environments without Docker or that need control over PostgreSQL, topology, services, and configuration.
• The homepage changes only its Download button label. Its Docker-first quick start (feat(home): offer Docker command and guided local setup #179) keeps linking to the Linux packages guide from its footer.
• It says "Linux packages", not "Native Linux", and the nav and hero button both read Install & Download.
• Docker offers the same two workflows as the homepage: Docker command and Guided setup (VS Code extension).

Rebased onto main after #179 merged.

Linux packages are pre-GA and support fresh installs only; the page and guides say so.

[xgerman]

The dedicated install-page work is strong, especially the Install → Set up → Connect and query flow, shareable selections, package-availability checks, and explicit distro/PostgreSQL/architecture choices. I do not think native Linux packages should become the homepage default or the generally Recommended path, though.

Our intended positioning should be:

• Docker is the default for evaluation and development. It is the supported paved path for quickly trying DocumentDB across Linux, macOS, and Windows and gives users a consistent topology.
• Linux packages are an advanced/alternative path for users who cannot use Docker or who intentionally need more control over PostgreSQL versions, topology, systemd integration, storage, configuration, or individual components.

That means the current hierarchy is reversed. This PR makes native packages the selected homepage quickstart, primary hero CTA, navbar destination, and “Recommended” option even though they currently cover only supported Linux distributions/PostgreSQL combinations and are explicitly pre-GA, fresh-install-only, with no in-place upgrade support.

I suggest:

1. Keep Get Started as the primary homepage CTA and make Docker the default quickstart.
2. Promote packages with a visible Linux packages or Advanced installation entry, but do not present them as the default for a general visitor.
3. On the install page, describe Docker container as “Recommended for evaluation and development” and Linux packages as “For environments without Docker or when you need control over PostgreSQL, topology, services, and configuration.”
4. Use Linux packages, not Native Linux. “Native” is ambiguous and may be read as CPU architecture or native binaries.
5. Consider Install & Download rather than replacing the navbar’s Download entry with Install, since users still need a clear route to release artifacts.
6. Reduce the duplicated installation UI on the homepage. The hero pitch, quickstart selector, and three-card installation section currently make installation mechanics dominate the product story. Keep the detailed choices on the dedicated install page.

This is closer to how comparable projects present the choice. OpenSearch recommends Docker Compose as the fastest way to try the product and puts Debian/RPM/tarball selections on its download page. Valkey keeps a general Get Started flow and lists containers and OS package managers neutrally in its installation documentation. Neither makes a limited native-package matrix the default homepage experience.

This also needs to be reconciled with #179. That PR proposes a separate Terminal/VS Code homepage selector, while this one proposes Linux packages/Docker. Rather than stacking competing dimensions, the homepage should retain one Docker-first quickstart; VS Code can be its guided Docker experience, while Linux packages lead to the advanced install page.

[guanzhousongmicrosoft]

Screenshots (local build; before = main, after = this PR)

Homepage: only the secondary button and nav label change. Docker quick start stays the default.

Before	After

Install page, default: Docker preselected and labelled recommended; Linux packages is the alternative.

Before	After

Docker → Guided setup (same two options as the homepage)

Linux packages flow: Install → Set up → Connect and query, with the pre-GA notice

Get Started primer

Before	After

Mobile (390px): Docker and Linux packages