fix(scraper): don't orphan the browser when a portal session fails to acquire

[delabrcd]

Problem

acquirePortalSession() launched Chromium, then ran newContext / newPage /
ensureLoggedIn unguarded. If any of those threw — a flaky login, an MFA
wall, a nav timeout — the PortalSession object that owns close() was never
returned, so the just-launched browser was orphaned.

The scheduled runner acquires one session per login every tick, so a
persistently failing login orphans a headless-Chrome on every retry. In a
real deployment this accumulated 200+ zombie chrome processes (~7 GiB) on
the non-prod instances, whose National-Grid logins fail. (Prod's login works,
so prod never leaked — which is why it went unnoticed.)

collect.ts had the same bug class in its own-browser path: it created the
context/page before the try/finally, so a throw there leaked too.

Fix

• session.ts — wrap every post-launch step in try/catch; close() the
  browser before rethrowing. Happy path unchanged (the returned session's
  close() still owns normal teardown).
• collect.ts — move newContext/newPage inside the try so a throw
  there reaches the finally that closes the own-browser.

Validation

• 1005/1005 unit tests pass (docker build --target test).
• Both changed files typecheck clean.
• No behavior change on the success path.