fix: merge-time follow-ups for #409, #404 and #399

#409 (Claude truecolor). The changeset becomes the changelog, and its premise
does not hold on tmux 3.2 or newer. Measured here on tmux 3.4: `default-terminal`
sits at its compiled default of `tmux-256color`, a live claude pane reports
`TERM=tmux-256color`, and supports-color reads that as 256 colors, where
rgb(55,55,55) lands on ESC[48;5;237m — visible, just not the color the theme
named. The invisible block the PR describes needs TERM to resolve to a 16-color
entry: tmux older than 3.2, or a ~/.tmux.conf setting `default-terminal screen`,
which Codeman's own tmux server does read (it passes no -f). Both the changeset
and the invariants paragraph now say that, so the next report here gets paired
with the reporter's tmux -V instead of being read as universal. The change itself
stands on the simpler argument: claude was one of two entries not asking for
truecolor while twelve do.

Also reorders buildClaudeEnv(). It applied the registry's unset/exports AFTER the
whole env was built, so a clis.json entry naming CODEMAN_HOOK_SECRET_FILE or PATH
would strip it on the direct-PTY path while the tmux pane kept it — buildEnvExports()
emits `...cliEnv` ahead of `export CODEMAN_MUX=1` and cannot. The block now runs
first and Codeman's own keys are assigned on top, matching the pane.

#404 (Ctrl+Z trap). Adds the missing changeset, and records what the trap does
not cover: an agent CLI already holds its tty with ISIG off (verified on three
live panes: `susp = ^Z -isig -icanon`), so this is defence for the startup window
rather than a fix for the steady state, and two input paths still reach the PTY
unfiltered — the mobile accessory bar's one-shot Ctrl and the CJK textarea.

#399 (path picker sort). The server sorts by name and cuts at 500, so the client
sorting those 500 by date gives "the newest of the first 500 by name", which is
wrong in exactly the >500-entry folder the date sort exists for. The status line
now says "(first 500 by name)" so the cut is legible, with the reasoning parked
on _sortEntries.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

src/web/public/keyboard-accessory.js

@@ -239,6 +239,14 @@ const PathPicker = {
    * way past it, not the thing being looked for. An entry without an mtime (an
    * older server, the in-container source) sorts after every dated one and then
    * by name, so a listing never degrades into an unstable order.
+   *
+   * ⚠️ This re-orders the listing the SERVER returned, and the server cuts at
+   * FILESYSTEM_PICKER_ENTRY_LIMIT (500) after sorting by name. So in a folder past
+   * that limit, "Newest first" is the newest of the first 500 BY NAME, not the newest
+   * in the folder — which is the one case this sort exists for. The status line says
+   * "(first 500 by name)" rather than "(first 500)" so the cut is legible; ordering
+   * before the cut would have to happen server-side, and would cost a stat on every
+   * entry in the directory rather than on the 500 that are returned.
    */
   _sortEntries(entries) {
     const [key, direction] = this._sortMode.split('-');
@@ -375,7 +383,7 @@ const PathPicker = {
     status.classList.remove('error');
     status.textContent = entries.length === 0
       ? 'This folder is empty'
-      : `${entries.length} item${entries.length === 1 ? '' : 's'}${this._truncated ? ' (first 500)' : ''}`;
+      : `${entries.length} item${entries.length === 1 ? '' : 's'}${this._truncated ? ' (first 500 by name)' : ''}`;
 
     const list = this.overlay.querySelector('.path-picker-list');
     list.replaceChildren();