Tighten the database migration observation: standby timeline and least privilege #5902

🤖 Generated by the Agentic Engineer

Problem

The read-only database observation added for the volume migration (platform#5845) has two small rough edges. They were found in its review and deferred so that PR could stay focused:

1. False hold after a failover. A standby reports its timeline from its last restartpoint, so right after a failover it can trail the primary. The observation then refuses a healthy cluster until the next restartpoint. This fails closed, so it is safe, but it can block a migration step for no reason.
2. More privilege than it needs. The observation only reads, but its workflow path still restores the Talos configuration and runs with the full admin cluster credential. The other migration operations also do not insist that the database choice is left empty.

Proposed change

• Read the standby's timeline from its WAL receiver instead of its last checkpoint.
• Skip the Talos configuration restore for the observation, and later give it a credential scoped to read and exec only.
• Require the database choice to be empty for every other operation.

Acceptance criteria

• A standby that has received the new timeline, but has not reached a restartpoint yet, is accepted. A standby on a different history is still refused, and a test proves both.
• The observation run does not restore the Talos configuration.
• Every operation other than the observation refuses a non-empty database choice.

Part of #5842