Protect authenticated live sessions from low-memory eviction

[isomorphisms]

Requirement

IB must protect an active authenticated transaction on a low-memory device from ordinary tab/app switching and renderer eviction.

The motivating class of workflow is a fragile government, benefits, banking, healthcare, or other form-driven site where the user is logged in and must temporarily open another tab or app to retrieve information. Opening that other program must not silently destroy the login, cookies/site-session state, navigation position, or in-progress form state and force the user to start over.

This is an IB live-browsing requirement, distinct from Pensieve's persistent indexing/link-graph role.

Architecture boundary

• Treat a user-marked or automatically recognized active transaction as protected live state, not an ordinary disposable sleeping tab.
• Authentication/session state required by the transaction must not be owned only by a renderer process.
• Under memory pressure, prefer evicting ordinary renderers before a protected transaction.
• Preserve enough browser-owned state to resume or reconstruct the transaction when a renderer is killed anyway.
• Do not require impossible cross-engine JavaScript-heap continuity. The requirement is to protect the user-visible authenticated transaction and avoid needless loss of state.
• Do not blindly persist secrets or sensitive field contents merely to satisfy restoration; the security boundary must be explicit.
• If exact restoration is impossible for a particular site, surface that limitation rather than silently presenting a fresh unauthenticated page as successful recovery.

Acceptance direction

Add a low-memory Android acceptance fixture that can:

1. establish an authenticated test session;
2. enter partial form state;
3. mark the transaction protected;
4. open another tab/app while memory pressure is induced;
5. return and verify the session is still authenticated and the intended form/task state is intact;
6. separately exercise renderer-process death and verify the strongest restoration IB actually provides.

Record separately whether the evidence proves cookie/session survival, form-state survival, renderer survival, or reconstruction after renderer death. Do not conflate them.

[isomorphisms]

First executable Android acceptance slice is on branch webview at head a6b00062fdc5bc551946059e0ea5533327edaf27.

It adds a separate android-webview/ harness with:

• loopback HttpOnly authenticated fixture session;
• ordinary vs synthetic-secret form fields;
• explicit protected WebView renderer priority;
• separate :pressure process for manual low-memory pressure;
• independent live-session/form/renderer receipts;
• API 29+ WebViewRenderProcess.terminate() renderer-death exercise;
• onRenderProcessGone reconstruction that restores URL/scroll/ordinary field but not the synthetic secret or JS heap.

Ubuntu Actions run 34855343470 is green: unit test, lint, debug APK build, boundary check, and artifact upload all passed. This is build evidence only. No physical-device session/form/renderer/reconstruction result is claimed yet, and host-process-death recovery remains explicitly out of scope for this first slice.

[isomorphisms]

Physical-device acceptance for the first Android WebView slice is now complete at exact head a6b00062fdc5bc551946059e0ea5533327edaf27 (Ubuntu build run 34855343470).

Observed on the physical Android phone in one acceptance run:

• API 34; ActivityManager.isLowRamDevice() = true
• WebView provider com.google.android.webview:151.0.7922.200
• protected checkpoint established with URL + scroll + ordinary field only; synthetic secret explicitly excluded
• after the separate pressure-process/app-switch exercise: switch.session=survived form=survived secret-live=present renderer=survived renderer-gone-events=0
• deterministic renderer termination: death.request=sent
• renderer exit observed: renderer-gone didCrash=false,priority=2
• reconstruction callback completed: death.reconstruction=observed
• post-death check: death.session=survived ordinary-form=reconstructed sensitive-form=not-restored heap=recreated reconstruction=observed renderer-gone-events=1 last-exit={didCrash=false,priority=2}

This physically proves, for this harness/device boundary:

1. authenticated cookie/session survival through the pressure/app-switch case;
2. ordinary in-progress form-state survival while the original renderer remains live;
3. survival of the protected renderer under that pressure case;
4. authenticated-session survival plus ordinary-field reconstruction after explicit renderer death;
5. the synthetic secret is not restored after renderer death;
6. the JavaScript heap is recreated rather than claimed continuous.

Still explicitly unclaimed: host-process-death recovery, durable persistence across app/process restart, arbitrary-site compatibility, secret-field restoration, or JavaScript-heap continuity. The current evidence is only the narrow issue-#59 renderer/session slice described above.