fix(messaging): revert sharedSecretCache reuse in getMessageHistory (regression hotfix)

[TortoiseWolfe]

Summary

Surgical revert of one change from PR #74 (batch 8) that introduced a Firefox/WebKit messaging E2E regression. All other batch 8 changes (non-extractable in-memory ECDH key, cursorRef pagination fix, console→logger, payment type narrow) remain intact.

Evidence — this is a real regression, not a flake

Run	Branch / commit	Date	Result
25306048649	main dd83ac7 (pre-batch-8)	today 07:14 UTC	✅ all green
25332113434	main 0e20fb3 (post-batch-8)	today 17:04 UTC	❌ firefox-msg failed
PR #70 rebased	33e7b80 (carries batch 8)	today	❌ webkit-msg failed
PR #75 first run	ca61ee7 (carries batch 8)	today	❌ firefox-msg failed

The very first post-batch-8 run on main reproduced the failure pattern. Pre-batch-8 main was green this morning. Causality chain is clear.

Failure symptoms

• Firefox/WebKit messaging tests time out waiting for cross-window message visibility
• message-delete-placeholder: getByText('[Message deleted]') resolved to 2 elements — duplicate render
• All failures involve the polling fallback (waitForMessageOnPage2)

Root cause

Batch 8 added a module-level shared-secret cache read-path in getMessageHistory (lines 772-802 of message-service.ts) to avoid re-deriving ECDH on every poll tick. The cache reuse is symmetric in design (same pattern as sendMessage's cache, which has been there for months) — but interacts badly with Firefox/WebKit reload + tab semantics.

Hypothesis: the cached CryptoKey reference behaves differently across these browsers when getCurrentKeys() returns a freshly-deserialized key from IndexedDB after a page reload. The invalidation guard cachedSenderPrivateKey !== currentKeys.privateKey was likely thrashing or holding a stale reference, causing decryption to use mismatched secrets.

What this PR does

getMessageHistory now derives a fresh shared secret per call, matching pre-batch-8 behavior. The cache infrastructure remains in place — sendMessage still uses it as before. This revert is read-path only.

Cost

~6 ECDH derivations/min under polling — measurable but not user-perceivable. A browser-safe instance-aware cache key can return as a separate change once the Firefox CryptoKey-reference behavior is properly understood.

What's preserved from batch 8

• ✅ Non-extractable in-memory ECDH private key (security fix, primary motivation)
• ✅ cursorRef pagination stale-closure fix in ConversationView
• ✅ console → logger.{debug,error} migration
• ✅ payment-service type narrow

Verification

• pnpm run type-check: clean
• pnpm run lint: clean
• pnpm test: 3237/3237 pass
• Husky pre-push (lint, type-check, unit, build): all green

Test plan

• CI runs the full E2E suite — Firefox/WebKit messaging shards expected to recover

Refs

• Introduced regression: PR fix(messaging): batch 8 — non-extractable in-memory ECDH key, polling cache, stale cursor #74 / commit 52becd7
• Last known-green main: run 25306048649 on dd83ac7
• First known-red main: run 25332113434 on 0e20fb3

🤖 Generated with Claude Code