guest-setup/public: raise the reboot timeout for bare metal

Bare metal guests power-cycle the whole platform on reboot, so firmware POST dominates how long they take to come back. Ansible's built-in reboot_timeout of 600 seconds cuts straight through the middle of that range.

Measured across 77 public ranch metal guest setups:

Generation	Vendor	n	median boot
5 (c5, c5d, c5n, m5, m5zn, z1d)	Intel	20	792s
6 (c6g, c6gd, m6g, m6gd, r6g)	Graviton	12	751s
7 (c7i, m7i)	Intel	14	531s
7 (c7g, c7gd, m7g, m7gd, r7g, r7gd)	Graviton	13	316s
8 (c8g, c8gd, m8g)	Graviton	7	218s

Generation 7 and 8 return in 202-583 seconds. Generation 5 and 6 need 706-820 seconds and never made the 600 second limit. Both metal pools mix the two groups, so which flavour a request lands on decides whether guest setup survives.

58b0abc0 replaced update-and-restart.yaml with testing_farm_profiles.library.update_and_reboot. The old task block carried ignore_errors, so a metal guest that overran the limit still finished guest setup: 32 of 62 metal setups in the weeks before that commit hit the timeout and nobody noticed. The role has no such guard, which turned them into hard failures.

Raising the limit to 1200 seconds covers the slowest observed boot with 46% headroom. wait_for_connection still gates guest health, so a guest that never comes back fails a few minutes later regardless. All 32 machines that overran the old limit reconnected, at 706-820 seconds.

Depends on profiles!96 (merged), which exposes update_and_reboot_task_reboot_timeout. Until that lands the variable is inert.

Resolves: TFT-5015

Generated-by: Claude Code