fix(serving): a patch gets the keyboard when it opens #1087

Part of #1086.

Keys go to the focused document. When a patch's frame loads, focus stays on the shell's document. So nothing in the patch hears the keyboard until the person clicks into the page: no shortcuts, no arrow keys, no Space to scroll. In #1052, with focus held on the shell, no hotkey fired before a click.

What changes

• The shell's frame load handler in packages/serving/src/broker.ts calls frame.focus() when nothing of the shell's holds focus (document.activeElement is null or body). If something does hold it, such as Patchy's bar or a download card, focus stays there. The prototype's two-line version is in prototype(sdk): give patches keyboard shortcuts like G H and Mod+K #1052.
• Scripted frames only, tiers 1 and 2. A tier 0 page has no broker and runs no code, and it is unchanged.
• Tier 2's starting cover already hands focus back to the frame when it closes (packages/serving/src/stream-status.ts). Check that path, and don't add a second handoff.
• Reloading the shell page focuses again. The broker is one-shot, so a second load of the same frame stops it rather than focusing. A route change doesn't reload the frame, so focus doesn't move.

Surfaces

• packages/serving/src/broker.ts.
• A test/browser-tier1 spec: a page that counts key presses, pressed after load with no click; and a run with shell UI focused first.
• Release impact: none. A revert puts back the click.

Done means

• Open a tier 1 patch and press a key without clicking: the patch's own keydown sees it. The same holds for tier 2 once its starting cover clears.
• Focus the shell's own UI before the frame loads, and it keeps focus.