v0.12.4

A large internal release with a deliberately small external surface: roughly 30,000 changed lines,
almost all of it code motion. The five largest god objects at 0.12.3 were decomposed into cohesive
units — both engine adapters into per-domain delegates, SessionService into a lifecycle owner plus
focused collaborators, InfraController into four controllers by resource, the plugin sandbox IPC
bridge out of the plugin loader, and the Chats dashboard page into per-section components — along
with the largest god methods in the webhook dispatcher, the queue processor, the bulk-message
batcher and the storage service. The largest single method in the codebase went from 8,366 to 4,819
characters.

None of it was meant to change behavior, and the HTTP contract bears that out: the 129 paths in
openapi.json, their methods, parameters, request bodies, response schemas, security requirements
and all 68 component schemas are identical to 0.12.3. The entries below cover the externally visible
consequences.

Changed

• 12 operationId values in openapi.json were renamed. InfraController was split into four
  controllers by resource — InfraStatusController, InfraConfigController, InfraDataController
  and InfraStorageController — and NestJS derives an operation's id from its controller class name,
  so every /api/infra operation is now Infra<Resource>Controller_<method> instead of
  InfraController_<method> (for example InfraController_getStatus →
  InfraStatusController_getStatus). 12 of the specification's 158 operations are affected, all of
  them under /api/infra.

  Nothing on the wire moved. The 129 paths, their HTTP methods, parameters, request bodies, response
  schemas, security requirements and the 68 component schemas are byte-identical to 0.12.3 — a client
  that calls the REST API by URL needs no change at all. The rename matters only if you generate a
  client from the specification and its generator names methods after operationId: those method
  names change, and the generated client has to be regenerated.

• A file attached but not yet sent in Dashboard > Chats is now dropped when you open a different
  conversation. Previously the staged file outlived the room it was picked in: attaching in one
  chat, going back, and opening another left the attachment sitting in the second chat's composer,
  where the next send would deliver it to the wrong recipient. It is now cleared as soon as another
  chat is opened, and cleared when the session is switched.

  Closing and reopening the same room still keeps it, so the round trip is lossless — the same
  guarantee the typed message draft already had. Both lifetimes are pinned by regression tests.