fix: fallback to single-thread init when mt startup fails

[maxkrut]

Summary

• add a timeout guard for multithreaded wasm initialization to avoid indefinitely pending Init() calls
• retry initialization with the single-thread wasm module when MT startup fails or times out
• keep existing behavior when MT initialization succeeds, while making fallback explicit and logged

Test plan

• npm run build-ts-api && npm run build-web-ifc-api-node
• npm test (fails in this local environment because ./web-ifc-node wasm runtime artifacts are not present)

[maxkrut]

Repro context for this fix:

1. Serve an app with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp.
2. Confirm self.crossOriginIsolated === true in the browser.
3. Call await ifcApi.Init() without forceSingleThread.
4. Make MT startup fail (for example, break pthread worker startup by blocking or mis-resolving worker/module assets).

Current behavior before this patch:

• Init() can remain pending indefinitely in this failure mode.

Expected behavior:

• if MT initialization fails (or does not complete in a reasonable time), initialization should fall back to ST (web-ifc.wasm) and resolve/reject deterministically instead of hanging forever.

This PR adds a timeout-guarded MT init path and retries with ST automatically.