Update workerd upstream

Update third_party/workerd without preserving obsolete fork implementations. Keep upstream behavior wherever it now satisfies open-compute, and keep every remaining fork seam narrow and reviewable.

Establish the exact state

Read the root and applicable workerd AGENTS.md files, docs/workerd/README.md, the active workerd design, and packages/runtime/workerd.lock.json. Confirm the parent and submodule worktrees are safe before rewriting history.

Fetch Cloudflare main into a dedicated local upstream ref and refresh the fork remote. Record the old fork head, upstream head, merge base, divergence, fork-only commits, changed paths, and parent gitlink. Do not treat commit subjects or git cherry alone as proof that upstream covers a fork feature: trace the upstream source and tests for the same behavior.

Minimize and regroup the fork

Rebase the current Day1 implementation onto the fetched upstream head. For each fork capability:

1. Drop code fully covered by upstream and use the upstream API directly. Prefer stock workerd configuration over a patch.
2. Adapt the smallest remaining open-compute seam to current upstream ownership and conventions.
3. Keep fork-specific files separate where doing so avoids recurring merge conflicts; touch upstream files only for the narrow registration or call site that must connect them.
4. Remove superseded helpers, flags, tests, and compatibility branches in the same rewrite.
5. Preserve security, capability, lifecycle, and resource-limit behavior; never resolve conflicts by weakening validation or silently ignoring configuration.

Keep a patch only when upstream lacks the capability and Cloudflare compatibility or a declared open-compute capability needs it. Record its purpose, upstream issue or PR, and removal condition in docs/workerd/README.md.

Produce one compileable commit per coherent open-compute capability. Fold tests into the capability they prove. Avoid merge, fixup, formatting-only, and historical compatibility commits. Rewrite the fork branch only when the user explicitly authorized it, and publish with --force-with-lease, never unguarded --force.

Validate and coordinate

Run focused formatting/build/tests while resolving each capability. Do not download runtimes implicitly. Before final acceptance, update the parent gitlink and the workerd source identity in docs. Change the formal multi-platform binary pin only as a coordinated pin update with verified archives, digests, version output, runtime config, and required product evidence.

Open Compute's formal workerd builds and FD-passing tests use --//:io_backend=cxx. Keep --@rules_rust//:extra_exec_rustc_flag=-Cstrip=none on macOS release builds: stripping the exec-configuration Rust proc-macro dylibs can produce a malformed Mach-O before C++ compilation begins. Treat these as recorded build inputs, not as generic upstream defaults, and do not use them to mask an unrelated compiler or linker failure.

Before the product Gate, explicitly build //src/workerd/server:host-extension-test-provider with the same C++ I/O backend and set OPEN_COMPUTE_TEST_HOST_EXTENSION_PROVIDER to its absolute executable path. The fixture is test-only and must not be added to the release pin or production artifact.

Run the static checks and the Gate targets the changed capabilities affect. Run the full workspace Gate only when the user asks or for a release. Use $cf-compatibility-check after implementation and fix its actionable findings. Report any platform build or formal-pin evidence that remains unavailable rather than substituting a development binary or a stock runtime.