e2e: expand schema-upgrade coverage — gaps not covered by #426

[WentingWu666666]

Context

Follow-up to #426, which adds the first two-phase extension schema-upgrade e2e spec (test/e2e/tests/upgrade/upgrade_schema_test.go). In review, @xgerman noted the PR intentionally covers only the happy-path single old→new hop and asked to file tickets for the explicit gaps. This issue tracks that future work.

Not covered by #426 (explicit gaps)

• spec.schemaVersion: "auto" single-step path — documented behavior but currently untested. Verify that auto migrates the schema in a single step (no separate finalize) and retains data.
• Rollback within the safe window — binary downgrade before finalize. In two-phase mode the schema stays at the old version, so a spec.documentDBVersion downgrade before setting schemaVersion should be safe; assert data + schema integrity across the down-hop.
• Negative / failure paths:
  • Migration failure (e.g. ALTER EXTENSION UPDATE fails) — operator surfaces the error, does not corrupt data.
  • Invalid / unpullable documentDBVersion — clear status condition, no crash-loop.
  • Skipping more than one minor (jump >1 version) — expected handling / rejection.
• Multi-instance / HA rollout ordering — the current spec pins INSTANCES=1. Cover a multi-replica cluster and assert rollout ordering and data availability during the schema upgrade.
• Multi-version chain — the current spec does a single old→new hop. Cover a chained upgrade across more than two versions.

Acceptance

Each gap above is either covered by an e2e spec (with appropriate labels/level) or explicitly deferred with a documented rationale.

Follow-up to #426.