Consider publishing the bridge-service TS client from the aggkit repo

[arnaubennassar]

Context

While reviewing agglayer/sdk#28 (aggkit bridge-service client + multi-network aggregator), @MaximusHaximus raised a structural question about where the bridge-service TypeScript client should live:

Fundamentally, I think it would be ideal if the client was defined and published from the aggkit repository that owns the actual REST API interface, and this SDK used a versioned copy of that client rather than the client existing here, built entirely into the SDK - it solves a lot of issues at once. I'm going to open a PR against Aggkit repo showing what that would look like as an example

That example is #1816 (POC: contract-first pipeline for the bridge service (one-route demo slice), draft, branch demo/spec-first-pipeline): a contract defined once (Zod schemas) generates both a strict Go server and a codec-validating TypeScript client, demonstrated against the global_index wire-format defect (/bridge/v1/bridges emits it as a bare JSON number, ≥ 2^64 for L1-origin bridges, while the committed swagger declares it a string — a defect class the generated client makes structurally impossible).

What this issue is

This is a "consider doing this" — not a decision to migrate. The reviewer proposed the approach and is providing a worked example; the team hasn't evaluated or endorsed it yet.

If a bridge-service client were owned and published from aggkit, several problems that currently live in agglayer/sdk's hand-written client (src/aggkit/client.ts, src/aggkit/aggregator.ts) would move upstream to where the wire contract is actually defined — wire-shape drift across rc releases, prose-based error identification, the global_index string/number workaround, etc. — instead of being re-discovered and patched downstream on every aggkit release.

What's not changing right now

agglayer/sdk#28 ships and keeps its embedded client for the imminent release; this is not blocking on that PR. If/when the team evaluates and endorses this direction, the sdk would migrate from its embedded client to a versioned client published from this repo.

For discussion

• Does the team want to pursue a contract-first (schema-generated) client published from aggkit, along the lines of POC: contract-first pipeline for the bridge service (one-route demo slice) #1816, or a different mechanism?
• If yes: release/versioning process for the client, how downstream consumers (agglayer/sdk, dev-ui) pin to it, and the migration path off the current embedded client.

cc @MaximusHaximus