Unmark DO facets as experimental.

[kentonv]

No description provided.

[ask-bonk]

There's no dedicated compat flag for facets. The feature was gated purely behind workerdExperimental. Now let me think through this change:

1. actor-state.h: Removes the workerdExperimental guard around facets property on DurableObjectState. Now unconditionally exposed.
2. worker-loader.h: Removes the workerdExperimental guard around getDurableObjectClass method on WorkerStub. Now unconditionally exposed, along with its TS override.
3. worker-loader-test.js: Removes allowExperimental: true and compatibilityFlags: ['experimental'] from dynamically loaded workers in tests.
4. worker-loader-test.wd-test: Changes "experimental" to "rpc" (which is actually needed for the RPC features the test uses).
5. server-test.c++: Bumps compat date to "2026-04-01" and removes "experimental" and "enable_ctx_exports" flags (the new compat date auto-enables enable_ctx_exports).

This is a straightforward change that makes the DO facets API available to all users rather than only to those who opt into experimental. The key question is: should this be gated behind a compatibility flag?

Since this is adding a new property (facets) to DurableObjectState and a new method (getDurableObjectClass) to WorkerStub that weren't previously accessible without experimental, this is additive. It doesn't change existing behavior -- it just makes new APIs available. Generally, new API additions don't need compat flags (those are for behavior changes). This looks safe.

LGTM

github run

[github-actions]

The generated output of @cloudflare/workers-types matches the snapshot in types/generated-snapshot 🎉