v1.23.2: >trim stops paying for the search index

v1.23.2 fixes the actual cause of the >trim timeouts that v1.23.1 made
visible: >trim was spending its whole time budget rebuilding the search
index, not trimming.

>trim was paying for a full index scan

Every aichat command runs an incremental index refresh first, walking every
session file in both agent homes. On the machine where this was found that is
13,656 files — about 4.5 seconds when there is essentially nothing to
do, and considerably longer with a backlog.

trim-in-place was paying that on every call, even though it never queries
the index; it resolves a path directly. And it runs under the >trim hook's
time budget. So the budget went on indexing:

	time
index refresh, nothing meaningful changed	4.46 s
the actual trim of a 20 MB session	0.29 s
aichat trim-in-place end to end, before	4.49 s
aichat trim-in-place end to end, after	0.36 s

With any real backlog the scan ran far longer — 30 seconds and more was
observed — which is what killed >trim outright.

Why it looked like a big-session problem, and wasn't

Every symptom pointed the wrong way until the timing was measured:

• The failures only ever showed up on large sessions, so the transcript
  looked guilty. It wasn't: a one-line transcript was just as slow,
  because the cost is the 13.6k-file walk, not the file being trimmed. Large
  sessions correlated only because they are the ones you reach for >trim
  on, and they are usually live and churning — which is exactly what gives
  the indexer something to do.
• aichat --version stayed instant, which made the CLI look healthy.
  --version exits before the group callback that does the indexing.
• Running the same trim through aichat resume worked fine every time. It
  pays exactly the same indexing cost — but interactively there is no
  timeout, so it just feels like a slow start.

The fix

trim-in-place now skips the index refresh, joining port and resolve.
Trimming rewrites the session file anyway, so indexing its pre-trim content
immediately beforehand was wasted work twice over. The next aichat command
picks the trimmed file up normally through its changed size and mtime.

Sessions you trim stay searchable; nothing about the index contract changes.

Keep an eye on

If >trim ever times out again, the diagnostic added in v1.23.1 still
applies: the message names the budget that expired, the transcript, which
aichat your PATH resolved to, a copy-pasteable command to reproduce it, and
whatever the CLI printed first. That diagnostic is what located this bug, on
its first real use.