fix: skip false starting-up copy when engine is already loaded

[quiet-node]

Summary

• Follow-up to fix: show cold-start loading label during engine warmup #287. The cold-start loading label ("Starting up the model…") could still show even when the built-in engine was already resident, because the label only knew about a wait, not the engine's actual lifecycle state.
• useEngineWarmupStatus now also tracks engine:status (engineState), and useEngineLoadingLabel branches on it: a genuinely cold engine still gets the phase-1 "starting up" / "reading weights" copy, but an already-loaded engine that's just slow (e.g. long-conversation prefill) gets a new dedicated phrase, "Processing your message…", instead of a false cold-start claim.
• /think turns now share the same label instead of ReasoningBlock's own hardcoded "Warming up..." string: ConversationView computes the engine label once and passes it down as pendingLabel, and the bare-dots row is suppressed for /think turns so the label only renders once (inside ReasoningBlock's pending row).
• ReasoningBlock's pending row and its clickable summary row now share one SUMMARY_ROW_CLASS constant plus an invisible chevron-width spacer, so the label lands at the same x-position whether or not thinking has started yet.

How it works

• EngineStatus['state'] (stopped | starting | loaded | stopping | failed) is already broadcast on engine:status; this only adds a subscriber.
• useEngineLoadingLabel's turn-lifecycle effect reads engineState once when a turn starts (like it already did for warming), and picks between the phase-1 schedule and the single ENGINE_SLOW_WARM_LABEL timer accordingly. The real warming signal still overrides either path the instant it fires, unchanged from before.

Testing

• bun run test:all:coverage — 2250 frontend + 1500 backend tests pass, 100% coverage on both.
• bun run validate-build — typecheck, lint, format, and build all clean (two pre-existing ESLint warnings in unrelated files, present on main, untouched by this diff).

Note: the chevron-spacer alignment is asserted structurally in tests (matching classes, same glyph, opacity-0 on the placeholder) rather than visually — this repo's UI is a native Tauri/NSPanel shell, not reachable through a plain browser dev server, so I wasn't able to eyeball the actual pixel alignment in this environment.