Renderer paste-then-Enter still uses a flat 50ms delay, so the startup draft prompt can submit empty on Windows

Split out of #15925 / #16586, which fixed the main-process path only.

## The gap

`src/renderer/src/lib/agent-paste-draft.ts:214` and `src/renderer/src/lib/active-agent-note-send.ts:217` write Enter a flat `POST_PASTE_SUBMIT_DELAY_MS = 50` ms after the paste (`agent-paste-draft.ts:36`). The Enter arrives as a text-less `terminal.send`, so `hasText` is false at the main-process suffix path and **no size-proportional delay is inserted at all**.

## Why it matters more than it looks

The caller is `src/renderer/src/components/terminal-pane/pty-connection/pane-serializer-settle.ts:125` — the **startup draft prompt**, i.e. the task you type into Orca's UI when creating a worktree. So this is the primary UI flow, not an edge case.

## The failure

Windows ConPTY ingests pasted input at roughly 96 B/ms (measured on two Win11 hosts in #15925). At a flat 50 ms the settle gap between `ESC[201~` and `\r` collapses above roughly **5 KB**.

Note the mechanism, because #15925's original framing had it wrong: nothing is truncated or reordered — node-pty's write queue is ordered, so `\r` always follows the paste bytes. What collapses is the *gap*. The child sees paste-end and Enter in effectively the same read, and an agent that attaches the paste asynchronously (React/Ink state update) processes Enter against pre-paste state.

**User-visible:** Enter submits an empty or previous-turn composer, and the pasted task lands afterwards and sits there unsent — the "task left in the input buffer" symptom from #15925, on the path most users actually hit.

Recoverable (press Enter again), silent, and easy to misread as the agent ignoring you.

## Fix

Route these through the same `getTerminalPasteIngestMs(platform, byteLength)` bound #16586 added, resolved from the pty's execution host rather than the renderer's platform. `AGENT_DRAFT_PASTE_MAX_BYTES` is 16 MiB (`src/renderer/src/lib/agent-draft-paste-content.ts:20`), so the uncapped case is reachable here too.

## Related, worth deciding together

`TERMINAL_INPUT_MAX_BYTES = 16 MiB` (`src/shared/terminal-input.ts:9`) and `AGENT_DRAFT_PASTE_MAX_BYTES = 16 MiB` are very large ceilings for an agent prompt. At 16 MiB the correct ingest wait is ~262 s. Capping around 1 MB would make that regime stop existing rather than be waited out.

Separately: any pre-Enter wait over ~2 s should show pane feedback. Post-#16586 a long wait is a designed outcome and is currently indistinguishable from the bug it fixes.