Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@frontend/app/block/blockenv.ts`:
- Around line 17-19: The BlockEnv type currently defines api.openExternal but
the actual env implementations (makeWaveEnvImpl, makeMockWaveEnv) expose
electron.openExternal, so useWaveEnv<BlockEnv>() will yield undefined for
waveEnv.api; fix by aligning the shape: either rename BlockEnv.api to electron
(update the BlockEnv interface and all consumers to use electron.openExternal)
or add a real api property to makeWaveEnvImpl and makeMockWaveEnv that forwards
to electron.openExternal (e.g., set env.api.openExternal =
env.electron.openExternal) so WaveEnvContext, useWaveEnv, BlockEnv,
makeWaveEnvImpl, and makeMockWaveEnv all share the same property names.

In `@frontend/app/block/durable-session-flyover.tsx`:
- Around line 29-34: The runtime error is caused by calling
waveEnv.api.openExternal where waveEnv.api is undefined; change the call to use
the actual runtime shape—invoke waveEnv.electron.openExternal(...) instead of
waveEnv.api.openExternal (locate the use in durable-session-flyover.tsx where
useWaveEnv<BlockEnv>() returns waveEnv and reference BlockEnv and
makeWaveEnvImpl to confirm the runtime fields), or alternatively add an api
wrapper onto the WaveEnv implementation in makeWaveEnvImpl so waveEnv.api is
defined; prefer the simpler fix of replacing waveEnv.api.openExternal with
waveEnv.electron.openExternal to match the real object shape.

In `@frontend/app/store/tab-model.ts`:
- Around line 49-53: Cache key for TabModel must include the WaveEnv so an
env-less instance doesn't win; update getTabModelByTabId to derive a composite
key from tabId plus a canonical identifier from waveEnv (e.g., env.id or a
stable string) instead of using tabId alone, and use that composite key when
calling tabModelCache.get(...) and tabModelCache.set(...). Ensure TabModel
construction still receives the passed waveEnv and update any helper like
getActiveTabModel to use the same key derivation so env-specific models are
returned consistently.
- Around line 80-87: Rename the hook function maybeUseTabModel to
useMaybeTabModel to follow React hook naming, change its return type from
TabModel to TabModel | undefined, and update its implementation signature
accordingly (it already calls useWaveEnv() and useContext(TabModelContext));
then update all call sites (notably the caller in aipanel.tsx) to handle the
possible undefined return (add a null/undefined check or early return) so
consumers no longer assume a guaranteed TabModel.

In `@frontend/app/store/wos.ts`:
- Around line 221-258: The derived-atom cache entries (created by
getWaveObjectAtom, getWaveObjectLoadingAtom, and isWaveObjectNullAtom) close
over the original wov and must be evicted when the backing WaveObjectValue is
dropped; update the cache-clearing logic
(cleanWaveObjectCache/clearWaveObjectCache) to also remove
waveObjectDerivedAtomCache entries for the same oref by deleting keys with the
suffixes ":value", ":loading", and ":isnull" so that subsequent getWaveObject*
calls recreate atoms bound to the new wov.dataAtom instead of returning stale,
disconnected atoms.

In `@frontend/preview/mock/mockwaveenv.ts`:
- Around line 175-183: getLocalHostDisplayNameAtom currently constructs a new
atom on every call, breaking atom identity; change it to return a cached
singleton like connStatusAtomCache: create a module-/mock-init-scoped variable
(e.g., localHostDisplayNameAtomCache) and initialize it once with the same
atom<string>((get) => { const configValue =
get(atoms.settingsAtom)?.["conn:localhostdisplayname"]; return configValue ??
"user@localhost"; }) then have getLocalHostDisplayNameAtom return that cached
instance instead of creating a new atom on each invocation so consumers (e.g.,
connectionbutton.tsx) subscribe to the same atom.

---

Outside diff comments:
In `@frontend/app/block/block.tsx`:
- Around line 306-323: The registry lookup and cleanup in BlockInner and
SubBlockInner can cause the new remounted instance to reuse a viewModel that the
old instance will dispose; fix by ensuring registry entries are keyed/validated
by viewType: when reading viewModel from
getBlockComponentModel(props.nodeModel.blockId) only accept it if
viewModel?.viewType === props.viewType, otherwise create a new viewModel via
makeViewModel(...) and register it with registerBlockComponentModel(...); in the
cleanup useEffect, only call unregisterBlockComponentModel(...) and
viewModel.dispose() if the current registry entry still points to this
instance’s viewModel (i.e., the registered model === viewModel) and change the
effect deps to [props.nodeModel.blockId, viewModel] so the cleanup is associated
with the correct instance; apply identical guards to SubBlockInner.

---

Nitpick comments:
In `@frontend/app/block/connectionbutton.tsx`:
- Line 24: The component is unnecessarily subscribing to changeConnModalAtom by
calling jotai.useAtom and discarding the value via _connModalOpen; replace that
subscription with a setter-only hook by using
jotai.useSetAtom(changeConnModalAtom) so the component no longer re-renders on
atom value changes—update the declaration that currently reads const
[_connModalOpen, setConnModalOpen] = jotai.useAtom(changeConnModalAtom) to use
useSetAtom and keep the existing setConnModalOpen reference.