fix(prompt): follow-ups from the OmO outcome holder review (#2186) #2190

Follow-up to #2186 (LOW notes from the merge pass's review; none blocked).

• Every OmO send now reads the holder records synchronously just before waiting for delivery (server/prompt.ts ~110-111, ~148/153; server/core/composer.ts ~539); on a large store that could block for the 194-815 ms measured per poll. Pass in an already known holder pid.
• Queued OmO sends read the holder records twice (server/core/pending.ts ~488 vs ~375); pass the pid through.
• Two OmO processes in one pane that both hold sessions bind to the first one herdr lists (same rule as fix(pending): bind a queued message to the agent process as command outcomes do, and read its birth without blocking #1986).
• Wrong holder for a queued outcome (Codex MEDIUM, server/core/pending.ts ~488, server/prompt.ts ~148): if two OmO holders in one pane reorder before delivery, a send queued for A is bound to B, and B's exit removes A's row (reproduced; needs two session holders in one pane). Keep the pending context's validated process identity when binding.
• Pid reuse between holder check and start read (Codex MEDIUM, server/prompt.ts ~103/148): a reused pid in that window records the replacement as the holder (reproduced with injected race). Keep and compare the verified pid and birth together.