Chat waiting copy: an immediate send has no PC stamp, so a PC clock correction or a long-idle tab still misjudges its turn #2974

Follow-up to #2973 (fixes #2949). That PR bounds a sent message's faded waiting copy by the PC's clock from each conversation read (x-server-time, also on 304), carried forward on the browser's monotonic clock, and by a PC stamp (sending_at) on a queued row. Codex's review of it left two windows for an immediate (composer) send. Both reproduce with bun -e probes against src/lib/sentWaiting.ts; neither is looser than main before #2973.

What still happens

1. The PC's clock is set back between the chat's last read and a send. The bound carries the last answer's PC time forward on the browser's monotonic clock, so it ends up later than the PC's clock after the correction. The send's own turn then looks older than the send, and its waiting copy stays beside it until it expires (60 s). A forward correction instead lets an older identical turn clear it.
2. A send long after the chat's last read. The bound allows 0.1% drift since that read: an hour without a read (a hidden tab) leaves 3.6 s in which an identical turn another device or the terminal wrote just before the send can clear its waiting copy.

Likely fix

Give an immediate send the same PC stamp a queued row has: the bridge takes its clock before it types the message and returns it with the submit result, and the browser matches the turn against that stamp. Keep the read-based bound for older bridges.