why: Validate the libtmux-protocol imsg engine against tmuxp's full test
suite and make wall-time comparisons against the subprocess engine
cheap to run.
what:
- Pin libtmux to the local libtmux-protocol worktree via tool.uv.sources
  (editable) so engine code is always exercised at HEAD
- Add justfile group 'engines' with test-subprocess, test-imsg,
  test-engines, and bench-engines recipes; both LIBTMUX_ENGINE env var
  and pytest --engine flag are set so non-fixture Server() instances
  also pick up the selected engine
- Update uv.lock for the local libtmux source

why: libtmux's pytest plugin now hardcodes default-shell /bin/sh in the
test config and autouse-pins $SHELL=/bin/sh, so the tmuxp-side
USING_ZSH apparatus (constant + autouse zshrc fixture) is dead code.
The fixture only existed to suppress zsh's first-run greeting that
interfered with output capture — irrelevant once tmux no longer
spawns zsh in test panes.
what:
- conftest.py: drop the USING_ZSH constant and the
  autouse-on-USING_ZSH zshrc fixture. ruff auto-removed the now
  unused `import os`

why: Python 3.15 ships the new profiling.sampling stdlib module
("Tachyon"), a statistical sampling profiler that produces flamegraphs,
heatmaps, and Gecko-format call trees with zero target instrumentation.
Mirror of libtmux-protocol's 21d9bcc4 so the editable libtmux install
and tmuxp share a profiler-capable interpreter when investigating
bench-engines wall-time questions.
what:
- .tool-versions: append 3.15.0a8 to the python line so `mise install`
  picks it up alongside the existing 3.10-3.14 matrix. The first entry
  (3.14) remains the default for project tooling; 3.15 is for ad-hoc
  profiling

…o 10ms

why: Empirical microbenchmark (60-pane test suite) measured the previous
50ms interval costing ~41ms more per pane on subprocess and ~35ms more
on imsg than a 10ms interval, because tmux's shell-ready latency lands
in the 50-150ms band and the coarser poll missed the early-readiness
window. Tightening to 10ms saves ~2.5s wall time on tmuxp's suite with
no correctness change — same condition, just polled more frequently.
what:
- _wait_for_pane_ready: change interval default from 0.05 to 0.01

why: the workspace builder's bulk option dispatch (next commit) uses
libtmux's pipelined ``Server.batch()`` API, which only ships on
the libtmux-protocol-engines branch. Repointing the editable pin
keeps tmuxp's test suite validating against the libtmux that has
the API the builder is about to call.
what:
- Switch [tool.uv.sources] libtmux path from ../libtmux-protocol to
  ../libtmux-protocol-engines.
- Update the inline comment to name every protocol engine the new
  pin exposes, not just imsg.
- Re-sync uv.lock against the new editable source.

… dispatch

why: tmuxp's workspace builder fires N round-trips per workspace
load applying session/window/options_after metadata, one
``set-option`` per loop iteration. Coalescing those into one
``Server.batch()`` collapses the round-trips into a single
pipelined write+flush on libtmux's control_mode engine while
remaining a no-op cost on subprocess and imsg. Helper lands first
without call-site changes so behaviour parity can be verified in
isolation.
what:
- Add ``WorkspaceBuilder._bulk_set_options(items, *, target,
  scope_flag)`` mirroring ``OptionsMixin.set_option``'s
  bool -> "on"/"off" normalisation (libtmux/options.py:661) so
  loop and batch paths produce identical tmux commands.
- Walk batch results post-flush and reuse libtmux's
  ``handle_option_error`` to preserve the ``OptionError``
  subclasses callers already catch, the same propagation
  ``OptionsMixin.set_option`` does inside its own body
  (options.py:711).
- Empty-dict guard avoids spawning a zero-command batch.
- Add two regression tests in tests/workspace/test_builder.py:
  ``test_bulk_set_options_propagates_unknown_option_error`` proves
  bad options still raise ``OptionError`` after the batch flushes;
  ``test_bulk_set_options_applies_session_window_and_options_after``
  exercises the helper across all three scopes (-s, -g, -w) and
  verifies each option lands on tmux via ``show_option`` /
  ``show-option -v``.

why: workspace loading dispatches one tmux ``set-option`` per loop
iteration across four hot loops (session options, global_options,
window options, options_after). Each call is a separate
round-trip; on libtmux's control_mode engine that's N stdin
write+flush pairs for purely metadata work. Routing the loops
through ``_bulk_set_options`` collapses each to one batched
``Server.batch()`` write+flush while leaving subprocess and imsg
engines on their existing per-call cost.
what:
- Replace the session ``options`` loop (builder.py:579-581) with
  ``_bulk_set_options(..., scope_flag="-s")`` targeting the
  session_id.
- Replace the ``global_options`` loop (builder.py:583-585) with
  ``_bulk_set_options(..., target=None, scope_flag="-g")``.
- Replace the per-window ``options`` loop inside
  ``iter_create_windows`` (builder.py:730-731) with
  ``_bulk_set_options(..., scope_flag="-w")`` targeting the
  window_id.
- Replace the ``options_after`` loop in ``config_after_window``
  (builder.py:903-904) with the same window-scoped helper call.
- ``set_environment`` loop and per-pane ``send_keys`` are
  intentionally untouched: different command shape and
  readiness-coupled sequencing respectively.