feat: add Effect-native client, contract, and worker packages

[bweis]

Introduces three new packages — @temporal-contract/contract-effect, @temporal-contract/client-effect, and @temporal-contract/worker-effect — providing a fully Effect-native alternative to the existing @swan-io/boxed-based stack

• All client methods return Effect<T, E> with Data.TaggedError errors, enabling typed Effect.catchTag / Effect.catchTags pattern matching instead of result.match({ Ok, Error })
• Activities are declared with declareActivitiesHandler / declareActivitiesHandlerWithLayer returning Effect<Output, ActivityError>, with optional Layer-based service injection via ManagedRuntime
• Adds order-processing-worker-effect integration test example covering executeWorkflow, startWorkflow, getHandle, describe, schema validation errors, Effect.catchTag recovery, and payment failure handling
• Docs site updated to include the three new packages in the API reference and copy pipeline

[bweis]

See: Effect-TS/effect#5986

[btravers]

Thank you for your contribution! I'm not deeply familiar with EffectTS, but providing an EffectTS version was actually something I had in mind for the future.

I have two questions though.

The first one is about the contract itself: right now the contract is agnostic of the scehma validation library used because it relies on Standard Schema, and I'm not sure this pattern can be followed with EffectTS. How would you approach that?

The second one is about the client and worker implementation. I think it would be valuable to have a reference implementation — the EffectTS version could be a good candidate for that — and then derive the other implementations from it. This way we'd share the core logic and guarantee a consistent feature set across all implementations.

What do you think?

[btravers]

Thank you so much for this, it's a lot of thoughtful work and I really appreciate it. 🙏

A quick update on where things landed since we last talked. I ended up reworking the error-handling foundation, and the project now standardizes on unthrown, a small errors-as-values library I wrote for it. The main draw is that it gives one Result model that works the same across the client, worker, and inside the workflow, which is the single consistent solution I was hoping for.

That workflow part is really the deciding factor: Effect doesn't run in Temporal's workflow sandbox (the issue you linked, Effect-TS/effect#5986), so a full Effect-native stack would still leave workflows on a different model. I'd rather keep the lightweight, uniform approach.

That said, nobody's locked out of Effect. unthrown ships an @unthrown/effect interop (plus neverthrow / boxed), so you can convert at the edge and use Effect freely in your own client/worker code.

So I'll close this one for now, but truly, thank you. I'd genuinely welcome a small docs example of the unthrown to Effect bridge if you're ever up for it. 🙌