docs(daemon): scope the draft-aware gap comments to the tested schedule

Two code-comment precisions on billbenetti's paste-side mitigation
(#3097), as its reviewers asked:
- seat-delivery-guard.ts: what happens after typing lands between the
  final check and the paste is stated for the tested append-mode
  schedule only, not as a guarantee.
- tmux.ts: the guard's checks run last, rather than its read being the
  last wait before the paste.

In the tested append-mode schedule, Enter is refused and nothing is submitted or deleted; this is no guarantee for every interleaving, and #3076 stays open.

This narrows #3097's merge message, which stated that outcome without the limit.

packages/daemon/src/adapters/tmux.ts

@@ -1103,9 +1103,8 @@ export class TmuxAdapter {
         // A paste the guard proves it left unsubmitted (#2429) is submitted first, under this lease, once this send's own
         // checks pass; they then aren't run a second time.
         beforePaste: async () => {
-          // This send's own checks can wait (a conversation lookup, an input capture), so they run first: the guard's
-          // read of the input is then the last wait before the paste (#3076). A check that refuses leaves a leftover's
-          // record for the next delivery.
+          // This send's own checks can wait (a conversation lookup, an input capture), so they run first, and the
+          // guard's checks run last (#3076). A check that refuses leaves a leftover's record for the next delivery.
           await options?.beforePaste?.();
           const checks = async () => { beforeWrite(); beforeInput?.(); };
           // The synchronous checks run again just before the key: the guard's re-read awaits after `checks`.

packages/daemon/src/domain/seat-delivery-guard.ts

@@ -516,7 +516,8 @@ export class SeatDeliveryGuard {
   /** No recent writable-client activity before a short wait, the input still empty when read again after it, and still
    *  no recent activity after that read. A time tmux can't report holds the paste, as an unreadable input does. The
    *  read it returns is the one the paste goes on. Typing after this final check and before the paste can still leave
-   *  the notice beside the person's draft: the Enter is then refused, nothing is submitted or deleted (#3076). */
+   *  the notice beside the person's draft. In the tested append-mode schedule the Enter is then refused and nothing is
+   *  submitted or deleted; that isn't a guarantee for every interleaving (#3076). */
   private async quietBeforePaste(target: GuardTarget, read: () => Promise<ComposerInput | null>,
     unknown: (reading: ComposerInput | null) => DeliveryGuardError): Promise<ComposerInput> {
     const quiet = async () => {