Pin the main-process renderer defenses in security-boundaries

[Pixnop]

While re-checking #335 I mutated six lines in the main process that the PR did not touch, one at a time, and ran the full suite after each. All six stay green:

• sandbox: false on the BrowserWindow webPreferences
• nodeIntegration: true on the same object
• script-src in the renderer CSP loosened to allow a remote host
• the will-navigate handler deleted
• setWindowOpenHandler returning { action: "allow" }
• the permission request handler answering true

Only the isAllowedRendererUrl widening (any app: host) dies today. tests/security-boundaries.test.ts pins the preload bridge, the CSP frame rules and the protocol wiring, but not these. Each one is a one-line regression that would ship a renderer with node access, a navigable window or an open permission model without a single red check, which is the exact class of mistake that file exists to catch.

Proposed: extend the source-text pins in the same style as the preload guard (anchored regex on the exact statement), one assertion per defense, and check each with its mutant before landing. A rendered-window probe through the existing smoke harness would be stronger for the handlers, but the text pins are cheap and close the gap now.

[Pixnop]

Shipped in v1.7.0-beta.8 via #367 (the pins) and #376 (denials must be direct, reachable statements). The one leftover, a trailing spread after the deny, is #378.