feat(tui): ephemeral memory storage for plugins

[kitlangton]

What

Adds a second storage tier to the TUI plugin API: context.storage.memory(key, { initial }). The existing storage.store is durable JSON persisted to disk; memory is an ephemeral in-process reactive store — synchronous updates, values need not be JSON-serializable, gone when the TUI exits.

The motivating consumer is plugin hot reload (split out of #39776): entries are memoized in the provider, above any single consumer's lifecycle, so a reloaded plugin generation re-acquires the same live store under the same key and its runtime state (timers' targets, positions, counters) survives the swap. This PR is useful standalone as cheap scratch state without a disk write per mutation.

How

• packages/tui/src/context/storage.tsx: memory map alongside the durable entries; each entry is a createStore + produce-based synchronous updater, memoized per key.
• packages/plugin/src/tui/context.ts: Storage.memory on the plugin-facing interface, plus doc comments contrasting the two tiers.
• packages/tui/src/plugin/context.tsx: plugin contexts expose it namespaced as plugin.<id>.<key>, same convention as store.

Scope

No persistence, no cross-instance sync, no eviction — by design. Hot-reload survival semantics are exercised end-to-end in #39776, which stacks on this.

Testing

• bun typecheck in packages/tui and packages/plugin
• bun test test/context/storage.test.tsx — new test covering synchronous updates, non-JSON values (a Date survives by identity), same-key store identity, and key isolation.
• Demo of the full behavior (physics state surviving hot reloads on camera): see the videos in feat(tui): hot-reload local TUI plugins #39776.

[kitlangton]

Superseded: #39776 was merged with these changes included (the branch stacked on this one), so storage.memory is already in v2. Closing.