[imneov]

What type of PR is this?

• feature
• bug fix
• documentation

What this PR does and why

Deploy and upgrade controls and YAML can show different values, and the upgrade YAML editor can start empty. This change shares the editing model between both views while keeping the existing form/edit persistence rules.

The form's Edit YAML action opens three panes: read-only deployment baseline, editable user YAML, and read-only server-composed effective configuration. Changing replicaCount from 2 to 3 in YAML updates the form to 3; changing it in the form updates YAML. Pasting only an image override retains the previously saved form replica count.

• Use the existing overrides, editsYAML, plan/diff/apply and dry-run APIs. No backend change, new capability or deployment-service upgrade is required.
• Preserve saved form settings omitted from YAML, unknown user keys and comments during structured edits, and invalid text until corrected.
• Seed upgrades from stored user settings and separately compare against the running revision's actual Helm values.
• Retain existing guarded recovery-timeout and adaptive-parameter cleanup. Effective preview follows the final request selected by that flow.
• Resolve GPU changes against the validated target, preserving unrelated affinity and selector groups. Read target defaults/site/catalog constraints and supported effective resources without requiring newer chart fields.
• Reject conflicting YAML service identity, stale async results and obsolete reviews; verify the running revision around planning and before apply.

Which issue(s) this PR fixes

Fixes #66.

How it was tested

• Both frontend TypeScript configurations passed.
• All 65 frontend test files / 605 tests passed.
• Console and standalone frontend production builds passed.
• Console go vet ./..., go test ./... and git diff --check passed.
• Regression coverage includes partial/empty YAML preserving saved form settings, existing bare-upgrade behavior, combined timeout/adaptive cleanup and final-preview parity, stored GPU selector/resource clearing, target-owned GPU constraints, older GPU charts, and service identity.
• Browser checks used the production components with fixture responses implementing the existing API: partial YAML retained replicas=2, form=3 updated YAML, YAML=4 updated the form and reached review; GPU automatic selection resolved target defaults; autoscale displayed configured=2/effective=4; the 390px layout had no document overflow.
• Production bundle inspection confirmed use of the existing YAML API and absence of new capability fields or fixture hooks.

Browser checks use fixture data. Live deployment and interruption/recovery were not performed. Full verification: docs/plans/2026-11-07-deployment-configuration-checks.md.

Checks

• Go tests/vet passed
• Frontend typecheck, tests and both production builds passed
• Design, existing API contract, verification log and changelog updated
• No new API, configuration permission or backend release dependency
• Chart lint is not applicable: no chart files changed

Notes for reviewers

Start with deployment-draft.ts, use-deployment-draft.ts and deployment-preview.ts, then deployment-gpu.ts, use-deployment-values.ts and the components. Model library/detail deployment and service list/detail upgrade share DeploySheet.

Design: docs/plans/2026-11-07-deployment-configuration.md. Existing API semantics: docs/plans/2026-11-07-deployment-values-contract.md.

Release note

Deploy and upgrade share synchronized form/YAML editing with baseline/effective previews and current-revision checks. Partial YAML preserves saved form settings using the existing deployment API.