Offer the installation's Runtime after an upgrade

[SaladDay]

What

When a Docker or microsandbox deployment's saved Runtime differs from the Runtime this console serves (/node-install/manifest.json), Settings → Sandbox and scheduling shows a Runtime row with both source commits (12 characters) and the action Use this installation's Runtime. The action opens the existing Change resources dialog on its review step with the served Runtime. Save configuration sends it through the existing PUT /core/v1/sandbox/deployment. Core then stores a new generation, and the page's Configuration rollout takes over. When the two Runtimes match, when the console serves no manifest, or during a reset, nothing new is shown.

• SandboxDeploymentSettings.tsx: reads the served release only when the deployment has a saved specification.runtime, compares all six release fields, and shows the row with its action.
• SandboxSetupWizard.tsx: new optional proposedRuntime prop. It seeds the edited Runtime and opens on the review step. Its only caller is the new action.
• sandbox-queries.ts: the wizard's inline manifest query becomes a shared distributionRuntimeQuery, used by the wizard and Settings. There is no new route or field.
• settings.css: .settings-row-content uses flex: 1 1 auto, so a long row value wraps its action onto the next line on phones instead of squeezing the text. Short values stay inline.
• Copy is in en and zh-CN.
• Docs:
  • apps/web/PRODUCT.md: Online sandbox configuration.
  • docs/getting-started/nodes.md (Change the sandbox configuration) and docs/web/console-api-usage.md, each in EN and zh, with refreshed source_hash.

Why

After the test cluster was upgraded, moving the microsandbox deployment to the new Runtime meant typing six identities by hand under Advanced settings. The saved Runtime always won, and Web never said that the console serves a different one.

Premises checked in code

• How Web reads the manifest. Web reads the console's /node-install/manifest.json through distributionRuntime. services/web serves it from the release that node-payload/active.json points to.
• How a Runtime change rolls out. A different Runtime makes ClassifyChange and Update (internal/deployment/execution.go) store the next generation and retain the previous one. Rollout then reports preparing.
• E2B. DeploymentPolicy.Runtime is false for E2B. Core rejects runtime for it, and deploymentContract.providers.e2b.runtime is false. The row needs a saved specification.runtime, so it never appears for E2B, and Settings never requests the manifest for it.
• Saved Runtime is kept. It is still kept unless the operator acts. The existing nodes.spec.ts test "edits only the saved backend, preserving a custom size and Runtime" still passes, and now runs with the row visible.

Verification

• pnpm --filter @oac/web typecheck: passed.
• vitest run on the sandbox wizard, queries, rollout summary, deployment specification and page ownership tests, plus the i18n test: 37 of 37 passed. The rollout summary test now wraps SandboxDeploymentSettings in a QueryClientProvider.
• Playwright, using the fixture with a local Chromium config override:
  • sandbox-generation.spec.ts: 9 of 9 passed, including the new test (saved Runtime A, served Runtime B; the row is shown, the action sends B, the row disappears and preparation starts).
  • nodes, unified-settings, sandbox-lifecycle, sandbox-rollout-details and sandbox-reset specs: 33 of 33 passed.
• pnpm --dir website build and pnpm --dir website test: 22 of 22 passed, including the translation hashes and link checks.
• make check-names and make check-docs: both passed.
• Screenshots: zh and en at 1440 px and 390 px.

Skipped

• Full make check and the full Web unit and acceptance suites (only focused checks were run).
• Go checks: no Go code changed.

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}