feat: opt-in persistent browser profiles (CAMOFOX_PERSISTENT_PROFILES)

[juniperbevensee]

Problem

Sessions are created with browser.newContext({ storageState }). storageState persists cookies + localStorage but not IndexedDB / Service Workers / Cache Storage. Sites that keep their auth in IndexedDB — Telegram Web (WebK) is a clear example — therefore can't be restored from a persisted session: after a session reaps and a new context is created, the user is logged out even though storage-state.json was reloaded.

Change

Opt-in persistent profiles. When CAMOFOX_PERSISTENT_PROFILES=1, a session launches a dedicated context via firefox.launchPersistentContext(userDataDir, …) instead of browser.newContext(…), keyed by sha256(userId) under CAMOFOX_USERDATA_DIR (default ~/.camofox/userdata). The full on-disk Firefox profile — IndexedDB included — then survives session reap/recreate (and, if the dir is on a volume, container recreate).

• Reuses the shared Xvfb display and the same camoufox launchOptions as the pooled browser, so persistent contexts get identical stealth.
• storageState injection is skipped for persistent sessions (the on-disk profile supersedes it).
• Opt-in because each persistent identity is its own browser process; with the flag off, the default shared-browser / ephemeral-context model is completely unchanged.

Two new config keys (lib/config.js): persistentProfiles, userDataDir.

Verification

Built the image, ran two containers (flag on / flag off), and for each: opened a tab, wrote a key to IndexedDB, closed the session, recreated it for the same userId, and read the key back.

Mode	IndexedDB value after session recreate
CAMOFOX_PERSISTENT_PROFILES=1	returned (survived)
default	MISSING (lost)

Notes / trade-offs

• Persistent contexts are one browser process per profile (heavier) — hence opt-in.
• Per-session granularity (rather than a global env flag) would be a natural follow-up if there's interest.

[skyfallsin]

thanks for putting this together. I’m thinking a little more about the persistent-profile approach and whether it’s the right boundary for this particular use case before committing either way. stay tuned.

[skyfallsin]

Thanks for the persistent-profile implementation and the clear verification work.

Since this PR was opened, the built-in persistence plugin gained opt-in IndexedDB storage-state support. This covers the stated login-persistence use case without adding one Firefox process and profile directory per user:

{
  "plugins": {
    "persistence": {
      "indexedDB": true
    }
  }
}

The branch is now conflicting and also includes unrelated VNC, URL-validation, and Docker changes. A persistent-profile mode would also need a redesigned reset/delete contract so DELETE /sessions/:userId/storage_state clears the on-disk Firefox profile, not only the storage-state file.

I am closing this PR as superseded by the current persistence path. Please open a new focused proposal if full Firefox-profile persistence is still needed for a case that IndexedDB storage state cannot support.