[Feature]: CSP-safe worker execution mode (remove the mandatory 'unsafe-eval') #134

Pre-flight checklist

• I searched existing issues and did not find a duplicate request.
• I explained the problem or use case, not just the desired API.

Problem or use case
concurrency currently revives worker bodies with new Function(...), which forces applications to allow 'unsafe-eval' in their Content-Security-Policy (plus worker-src blob:). This is a non-starter for security-conscious deployments and is self-contradictory in a framework that ships a security module and markets "secure by default." It is the primary blocker to concurrency leaving Experimental (#133).

Proposed solution
Provide a default execution mode that does not require 'unsafe-eval' — for example, dispatching to pre-registered module workers addressed by URL (static Worker(new URL(...))) and passing only serializable payloads, rather than serializing function bodies for eval-based revival. Keep the current dynamic mode available as an explicit opt-in for users who accept the CSP trade-off, but make the safe mode the documented default so the out-of-the-box posture is CSP-clean.

Possible API or UX shape

import { createPool, defineWorker } from "@bquery/bquery/concurrency";

// Registered module worker — no eval, CSP-clean.
const heavy = defineWorker(new URL("./heavy.worker.ts", import.meta.url));

const pool = createPool({ mode: "module" }); // "module" (default) | "dynamic" (opt-in, needs unsafe-eval)
const result = await pool.run(heavy, payload);

Alternatives considered
Documenting the CSP requirement and leaving it as-is — unacceptable for a security-first framework and an adoption blocker. Dropping dynamic function workers entirely — too disruptive for existing users; keeping them as an explicit opt-in preserves flexibility while fixing the default.

Relevant area
concurrency

Additional context
Also relevant to security. createSharedBuffer()'s crossOriginIsolated requirement is inherent to SharedArrayBuffer and can stay documented as-is; this ticket is specifically about removing the eval requirement, which is bQuery's own implementation choice rather than a platform constraint.