First 'New chat' is slow because pi runtime is lazily initialized (not pre-warmed at boot)

Description

The first "New chat" after launching ThinkRail (desktop app or CLI) takes several seconds to open. Subsequent new chats open instantly. This is caused by lazy initialization of the in-process pi runtime: getPiRuntimeGeneration() in packages/server/src/agent/piRuntime.ts is only triggered on the first session/model request, and the first call does a full ModelRuntime.create() + extension/skill reload, which is expensive.

Steps to reproduce

1. Launch the ThinkRail desktop app (or thinkrail CLI and open a workspace).
2. Wait for the UI to be fully loaded.
3. Click "New chat".
4. Observe the delay before the chat input appears.

Note: step 3 is slow only on the first new chat after launch; the second new chat opens immediately.

Expected behavior

The chat should open immediately (or the pi runtime should be pre-warmed at boot so the first interaction is not delayed).

Actual behavior

The first new chat blocks for seconds while the pi runtime boots. From the code:

• packages/server/src/agent/piRuntime.ts — getPiRuntimeGeneration() lazily creates the runtime on first use; createRuntimeWithExtensions() runs advanceExtensionCacheGeneration() (2× DefaultResourceLoader.reload()), ModelRuntime.create(), createAgentSessionServices() with JITI_REBUILD_FS_CACHE=1, then a further buildResourceLoader() reload.
• packages/server/src/host/boot.ts — bootHost() never touches the pi runtime (no pre-warm call).
• The pre-warm hooks already exist (configurePiRuntimeGenerationInitializer, preparePiRuntimeGeneration) but are not wired into boot.

So the "wait" is the first createSession() / model.list paying for a full runtime bootstrap that could have been done in the background at app launch.

Environment

• OS: macOS 26.6.2 (arm64)
• Bun version: 1.3.14
• Node version: v24.16.0
• ThinkRail version / commit: 0.1.0-nightly.33 (also present in v0.0.19)

Start in packages/server/src/agent/piRuntime.ts by tracing configurePiRuntimeGenerationInitializer and preparePiRuntimeGeneration, then inspect packages/server/src/host/boot.ts to see how bootHost can invoke the existing pre-warm hooks. Reproduce the first-chat delay in the desktop app or thinkrail CLI; done means the pi runtime is prepared during launch and the first new chat no longer waits for runtime initialization.