Route unexpected taskpane errors through a generic user-facing message

[dobby-coder]

A draft security advisory has been filed for the taskpane's error-surfacing path. Details (impact, root cause, affected lines) are in the private advisory — not repeated here to avoid public disclosure:

https://github.com/encryption4all/postguard-outlook-addon/security/advisories/GHSA-hv6m-xwjr-m2f6

Scope of the work (see advisory for specifics):

• Introduce an explicit "this message was written for the user" error marker in src/lib/, and use it for the validation failures that src/taskpane/compose-view.ts throws on purpose.
• In the catch blocks of src/taskpane/compose-view.ts and src/taskpane/read-view.ts, show the marked message when present and a generic localized message (t("encryptionError") / t("decryptionError")) otherwise, with the raw value logged via console.error for DevTools only. This matches encryptionFailureMessage() in src/launchevent/launchevent.ts:95-105, which already does this on the send path.
• Replace the ad-hoc /KEM/i message test in read-view.ts with a check that does not depend on matching SDK message text.
• Add node:test coverage for the routing (marked error → own message; arbitrary error → generic message).

Repo maintainers/collaborators can view the advisory thread for full context. Same shape as #123.

[dobby-coder]

/dobby fix — Implement the scope described in the issue body: add a user-facing-error marker in src/lib/, use it for the deliberate validation throws in encryptAndPrepareSend, and route everything else in the catch blocks of src/taskpane/compose-view.ts and src/taskpane/read-view.ts to the generic localized message with the raw value logged via console.error only — mirroring encryptionFailureMessage() in src/launchevent/launchevent.ts. Also drop the /KEM/i message-text test in read-view.ts in favour of a check that does not depend on SDK message wording, and add node:test coverage for the routing. Keep the commit message and PR title generic (e.g. "harden taskpane error surfacing") and do not describe the leak in public artifacts — the detail lives in the linked draft advisory. Run npm test, npx tsc --noEmit and the eslint/prettier CI commands before opening a draft PR.

[dobby-coder]

On it! I'm implementing the fix from the issue: adding a user-facing-error marker in src/lib/, wiring it into encryptAndPrepareSend's validation throws, and routing the compose-view.ts / read-view.ts catch blocks to the generic localized message (raw errors going to console.error only), mirroring launchevent.ts. I'll also swap out the /KEM/i message check in read-view.ts for something SDK-wording-independent and add node:test coverage for the routing.

I'll run npm test, npx tsc --noEmit, and the lint/format checks before putting up the draft PR.

[dobby-coder]

Parked: this is dobby-initiated work coupled to @rubenhensen, who already has 3 dobby PRs waiting for review (budget: 3). I'm not opening another one until some of those merge or close — comment here to re-trigger dobby once there's room.