feat(ci): integrates stainless client lib gen into ci

[zcabter]

Context

This PR sets up Stainless Github Action to automatically generate the client library and push changes to jstz-client repo. The auto generated bindings will be useful as we continue to evolve the Jstz node endpoints and communication bindings.

Generated code: https://github.com/jstz-dev/jstz-client

Description

• Adds generate client job
• Adds stainless.yaml config
• Represents operation hash as byte array

Evaluation

Evaluation doc: https://docs.google.com/document/d/1kU_xjPYoHaqgmewAZlJDpkJ25FTNnccq8Wb88YQhcFk/edit?usp=sharing

	Description	Stainless
Code quality	Coherent generated code: (M1) Separation by resource, (M2) Sensible calling conventions and method names, (M3) Able to return the body type and Response, async, (M4) Idiomatic use of Typescript (M5) Package size(M6) Fetch configurability	(M1) + Types /Classes are separated by resource(M1) - Sub-resources are child types of resource ie. Type for subkey list is Jstz.Accounts.Kv.SubkeyListResponse(M2) + Calling convention are resource based ie. client.accounts.kv.subkeys.list(address)(M3) + Response are returned as Core.APIPromise, an awaitable promises that returns T or can be converted into Response with asResponse() or withResponse()(M4) + OO Typescript(M4) + Namespaces to void conflicts(M6) + Client customisation eg. timeout, retries, custom fetch, agent for managing connections (M6) ~ Streamable response support via fetch API - cannot mark endpoint as returning a stream (could be an OAS definition problem)
Runtime compatibility		Node.js, Deno, Bun, browsers, and variousedge runtimes, as well as both CommonJS (CJS) and EcmaScript Modules (ESM).
Mock and testing		Fetch can be mocked
Customisability	Degree and ease of customising the code generation	+ Method names, model references, and organisation can be controlled via stainless.yml config+ Patching with custom code by replaying patches for each generation
Language support		+ Typescript- No Rust, not in roadmap~ SDK docs in roadmap
Developer experience		- No offline generation- No LSP to aid writing stainless configs~ Basic documentation
CI Integration	Degree and ease of integrating into CI	+ GHA support- Dependent on Stainless platform to perform the code generation
Compatibility with OpenAPI 3.1	Utopia generates OAS v3.1	Yes

Manually testing the PR

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 45.23%. Comparing base (92e6a62) to head (838594a).
Report is 1 commits behind head on main.

Files with missing lines	Coverage Δ
crates/jstz_proto/src/operation.rs	26.96% <100.00%> (+5.27%)	⬆️
crates/jstz_proto/src/receipt.rs	65.00% <ø> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 92e6a62...838594a. Read the comment docs.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[zcabter]

Generating a new client sdk should only happen on main branch. The ci file needs to be updated before merging.

[huancheng-trili]

Will there be any issue if we move all changes to the source files to #663 and only keep the yaml files in this PR? I think that looks cleaner.

[zcabter]

Will there be any issue if we move all changes to the source files to #663 and only keep the yaml files in this PR? I think that looks cleaner.

Done