chore(lit-actions): upgrade Deno runtime stack

[clawdbot-glitch003]

Summary

• Upgrade the lit-actions Deno crate stack to Deno v2.8.0-era versions (deno_core, deno_runtime, deno_lib, deno_resolver, deno_error, sys_traits)
• Update SWC pins and Rust code for upstream API drift in ops, snapshots, module loading, workers, error formatting, and SWC WTF-8 strings
• Preserve runtime behavior for Lit Actions by wiring residual lazy extension sources from snapshot creation into worker startup
• Fix fetch/TLS under rustls 0.23 by explicitly installing the aws-lc-rs crypto provider and using the no-provider reqwest feature
• Adjust integration warmup timing for the slower upgraded Deno boot path under concurrent tests

Validation

• git diff --check
• cargo fmt --all
• cargo test -p lit-actions-server --lib -j 2 — 86 passed
• cargo test -p lit-actions-tests --test integration -j 2 — 26 passed, 2 ignored
• cargo test --workspace -j 2

Notes

• Local root disk is tight after rebuilding Rust targets: / was 98% used with ~3.5G free during validation.
• The Deno stack update removes the previous Lit fork patch for deno_core and the macOS libffi patch because the upgraded dependency graph no longer needs them.

[GTC6244]

@glitch003 - looks pretty good and I'd give it a conditional pass, based on the fact that it works !

My notes inline are really about running profiling tests, which I'll do today.

[GTC6244]

I'm assuming this skips all of the manual ESM work that I had Claude put together - but will need to load test, and/or profile to be sure.

[GTC6244]

While this is in the test path, the comment makes me believe that timing may be changing in the processing. On the one hand, reducing the TTL of the actual runtime is good, but lazy-loading after the fact may ( or may not ) make the entire process a bit slower. Suspect this is a nanosecond thing - but for clients like Relay, this may make a difference.

To be more specific, we're caching deno environments entirely, so I'd prefer to do as much hydration prior to deno saying it's ready to process !

Again, profiling is the answer here.