feat: bottom-dock extension dialogs, declutter titles, unlock full extension UIs

[luckrnx09]

What

Three interaction fixes for extension UI requests (select/confirm/input/editor + custom panels), reported in #679 and related pain points:

1. Bottom-docked cards instead of centered modals — ExtensionDialog and ExtensionCustomPanel now anchor above the composer. The chat stays scrollable while a request is open, so users can re-read context before answering (希望AskUserQuestion，可以换成非弹窗 #679).
2. Multi-paragraph titles split into header + body — hosts/extensions that fold context into the title (previews, instructions, [header] prefixes) now render the first paragraph as the header and the rest as scrollable body text, instead of cramming everything into the title row.
3. Attention sound debounced across chained dialogs — a select followed by an input (the "type your own answer" flow) is one interaction and now rings once, not twice.
4. Advertise mode: "tui" to extensions — pi-web runs the agent in-process and its uiContext.custom() is fully implemented (terminal-rendered panel), but extensions were told "rpc", so extensions with rich TUI components (e.g. tabbed multi-question questionnaires with checkboxes) degraded to sequential select/input dialogs. The label now matches actual capabilities, unlocking their native UIs.

Verification

• npm test (956 pass), eslint, tsc --noEmit clean
• Source-assertion tests added for docking, sound debounce, and title splitting
• Playwright geometry check: dialog bottom sits above the composer, chat scrolls while open
• Real-extension end-to-end check with a questionnaire extension: full multi-select checkbox questionnaire renders and submits through the custom panel

Collapsed-pill behavior, keyboard navigation, draft preservation, and Esc semantics are unchanged (covered by existing e2e fixture).

[luckrnx09]

@agegr Adapt and extend in the web UI (especially custom terminal UI) is really tricky.

How about just using the custom UI from the Terminal? Although its interaction feels quite abrupt compared to web components, it would ensure that the extension's functionality matches TUI without introducing compatibility issues.

This PR is just my initial idea and hasn't been fully tested yet.
If you're interested, let me know what you think so I can decide whether to move forward with it or not.