Takeover runbook still calls itself 'not a qualified procedure' while docs and the 3.0 launch send users to it #987

docs/rust-server-upgrade-takeover.md opens: "It is a design input for #325, not a qualified procedure … upgrade-inspect … takeover_allowed flags are always false." But:

• its own Deprecation section says takeover ships in 3.0.0 for PHP layouts 2.5.14–2.11.8;
• durable-workflow-server upgrade-takeover is implemented (rust/src/main.rs → runtime::upgrade::takeover, requiring DW_UPGRADE_BACKUP_FINGERPRINT and the original queue binding), and the inspect reports are read-only by design, so takeover_allowed:false there is expected;
• the native install docs (durable-workflow.github.io#426) and the 3.0 launch post (Complete failed updates in the Rust server #427) point existing PHP users to this runbook as the upgrade path.

Needed before the 3.0.3 launch post publishes:

1. Link the evidence that qualified upgrade-takeover for 3.0.x: which layouts and backends, the installed acceptance runs, and the Security acceptance. If it isn't qualified, say so plainly, and the docs and post must not present takeover as the supported upgrade path.
2. Rewrite the opening as an operator procedure: prerequisites (2.5.14+, a verified backup and its fingerprint, PHP quiesced), the exact commands in order, how to verify success, and what to do on refusal. Explain that the inspect commands never report takeover_allowed:true and why.
3. Check the schedule-restriction paragraph, which the launch-post review found out of date: native now supports cron schedules.

Owner: Server lane (agent offline; General tracking). Blocks: durable-workflow.github.io#427 publish.