Restore --unsafely-treat-insecure-origin-as-secure flag for Blazor WASM Lighthouse scenario

[ilonatommy]

Blazor WASM requires crypto.subtle, which is only available in secure contexts (HTTPS or localhost). This restores the --unsafely-treat-insecure-origin-as-secure Chromium flag so the Lighthouse benchmark can run against non-HTTPS targets.

Original error:

[Browser]: MONO_WASM: Assert failed: This engine doesn't support crypto.subtle. Please use a modern version. Error: Assert failed: This engine doesn't support crypto.subtle. Please use a modern version.

See: https://dev.azure.com/dnceng/internal/_build/results?buildId=2916489&view=logs&j=11a54114-a913-5aee-3e37-a7e79dd06658&t=dce0fd39-734b-57d9-3c15-08dd4b8e31d5, "Blazor Web (WebAssembly)" or "Blazor Web (Auto)"

Further errors discovered when fixing the initial one:

[STDERR] file:///src/src/blazor-scenario.js:136
[STDERR]       throw new Error(`Unexpected uncached wasm resource '${url}'`);
[STDERR]             ^
[STDERR] 
[STDERR] Error: Unexpected uncached wasm resource 'http://10.0.0.102:5000/_framework/System.Runtime.InteropServices.JavaScript.xzugz00is9.wasm'
[STDERR]     at file:///src/src/blazor-scenario.js:136:13
[STDERR]     at file:///src/node_modules/puppeteer-core/lib/esm/third_party/mitt/mitt.js:36:7
[STDERR]     at Array.map (<anonymous>)
[STDERR]     at Object.emit (file:///src/node_modules/puppeteer-core/lib/esm/third_party/mitt/mitt.js:35:20)
[STDERR]     at CdpPage.emit (file:///src/node_modules/puppeteer-core/lib/esm/puppeteer/common/EventEmitter.js:77:23)
[STDERR]     at file:///src/node_modules/puppeteer-core/lib/esm/puppeteer/cdp/Page.js:177:18
[STDERR]     at file:///src/node_modules/puppeteer-core/lib/esm/third_party/mitt/mitt.js:36:7
[STDERR]     at Array.map (<anonymous>)
[STDERR]     at Object.emit (file:///src/node_modules/puppeteer-core/lib/esm/third_party/mitt/mitt.js:35:20)
[STDERR]     at NetworkManager.emit (file:///src/node_modules/puppeteer-core/lib/esm/puppeteer/common/EventEmitter.js:77:23)

build

At the time of adding the check for response.status .wasm resources were not fingerprinted (#1944). They used stable filenames with ETag/Last-Modified caching, where the browser would always make a conditional request and get a 304. Since then, Blazor switched to fingerprinted filenames (e.g., *.xzugz00is9.wasm), which triggers Cache-Control: immutable — meaning the browser serves from cache directly (200 from cache) with no server round-trip, so 304 never occurs.

Verification

AzDo build, job WebAssembly and Auto: build