feat(shot): lay previews out as with an on-screen keyboard

[koji-1009]

shutter shot --keyboard <height> lays every preview out as a device does while its on-screen keyboard is up: the view reports a bottom inset of that many logical pixels (MediaQuery.viewInsets) from the first frame.
Text entered with --enter used to be shot without the keyboard's effect on the layout; with --keyboard, a screen that overflows, hides a button, or does not scroll to the field under the keyboard shows it in the image.

• A Scaffold shrinks its body above the keyboard (not with resizeToAvoidBottomInset: false), and so does a layout of the app's own that pads by MediaQuery.viewInsetsOf; a widget that does not read the inset is shot unchanged.
• The keyboard is not drawn: with --capture screen, the area it covers shows what the app paints there.
• No default height, since keyboards differ by device and input method.
• manifest.json records keyboard, shot prints it, and diff prints both runs' when they differ; shot ids are unchanged, so a run with --keyboard pairs with one without.
• Experimental in doc/manual.md; doc/agent.md gains one bullet. An e2e test checks the three layouts above and the screen capture pixel by pixel.

Images

The e2e test's previews (200×300), shot without --keyboard, with --keyboard 100, and with --keyboard 100 --capture screen --viewport 200x300.
The red bar ends at the bottom of the preview, and above the 100-high keyboard when the layout reads the inset.

preview	no keyboard	--keyboard 100	--keyboard 100 --capture screen
Scaffold, green background
Scaffold(resizeToAvoidBottomInset: false)
own layout padding by MediaQuery.viewInsetsOf

🤖 Generated with Claude Code

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!