Docs(topics[automation]): Wait for tmux, don't guess

why: The examples slept a fixed amount and then read the pane. Measured,
send_keys to visible in capture_pane is 100ms at the median under a
parallel test run, so the 100ms sleeps had no headroom at all -- the
"Capturing output between markers" example fails deterministically at
--reruns 0 today, and the repo default of --reruns=2 hides it. Several
checks were also searching the joined capture, which matches the command
tmux echoed onto the pane and is true before the shell has run.

what:
- Have commands signal a tmux channel and block on Server.wait_for,
  which returns when the command is actually done
- Compare whole captured lines instead of searching the joined capture
- Keep sleeps only where the example is about elapsed time itself

Author: tony

CHANGES

@@ -47,6 +47,20 @@ _Notes on the upcoming release will go here._
 
 ### Documentation
 
+#### Automation patterns waits for tmux instead of guessing (#734)
+
+The examples on {ref}`automation-patterns` waited for a command to finish by
+sleeping a fixed amount and then reading the pane. A sleep long enough to be
+safe is dead time on every run, and one short enough to feel quick reports
+failure on a busy machine.
+
+They now have the command signal a channel when it finishes and block on that
+with {meth}`Server.wait_for() <libtmux.Server.wait_for>`, which returns the
+moment the command is done. Checks compare whole captured lines rather than
+searching the joined capture, because {meth}`~libtmux.Pane.capture_pane`
+returns the command tmux echoed onto the pane -- a substring search matches
+that echo and is already true before the shell has run.
+
 #### Cleaner `from_env` examples (#719)
 
 The rendered examples for {meth}`Pane.from_env() <libtmux.Pane.from_env>` and