fix: avoid IndexedDB handle writes during tab unload

[kbuffardi]

Summary

• split FileSystemDirectoryHandle persistence from serializable session-state persistence
• save directory handles at folder acquisition/reconnection instead of during tab teardown
• proactively debounce active-editor and tab state so restore no longer depends on unload
• keep beforeunload synchronous and limited to compiler-worker termination
• add regression coverage for persistence boundaries, startup gating, editor snapshots, and unload behavior

Context

Issue #92 was narrowed to an unload-time IndexedDB operation. Closing the extension without opening a folder did not crash, opening any folder did crash, and overriding IDBFactory.prototype.open to throw before closing prevented the crash. The affected path called persistenceGate.persist() from beforeunload, which opened IndexedDB and stored the live directory handle.

This PR avoids that native Chrome crash path without changing STOP, compiler-worker replacement, terminal output, or the existing IndexedDB schema.

Verification

• npm run test:e2e — passed, 199 tests
• npm run lint — passed
• npm run build — passed; existing webpack bundle-size warnings only
• npm run test:browser:chrome — compiler/link preflight passed, then the existing hosted smoke path failed its unrelated xterm stream-output assertion because it read injected renderer CSS instead of terminal text

Manual QA required

The automated harness cannot obtain the same native FileSystemDirectoryHandle used by the crash reproduction. Before merging, verify on the affected Chrome/macOS environment:

1. Open and close browser.cpp without a folder.
2. Open an empty folder, wait briefly, close the tab, relaunch, restore, and close again.
3. Open the original project without running it and close the tab.
4. Run and STOP the original infinite-output program, then close the tab.
5. Confirm Chrome remains alive and no new crash report is uploaded.

Assumptions and limitations

• This is an application-side avoidance of a native Chrome failure, not a fix to Chrome itself.
• A very recent editor change is persisted after the existing 300 ms debounce rather than by an unreliable unload write.
• The real native-handle close path still requires reporter-profile verification.

Closes #92