Multi-chain intent model: intents need to know which chain they settle on #26

The intent model has no chain field. The dApp now routes per chain (/arc/*, /stellar/*) and connects wallets on both, so an intent submitted from the Stellar side is indistinguishable from an Arc one once it reaches this service — and would settle against the wrong contracts.

Scope

• Add a chain discriminator to the intent model and the create DTO
• Store the user's address in that chain's format: 0x... for Arc, G... for Stellar
• Route settlement to the right chain client and contract set
• Reject an intent whose chain has no deployed contracts, with a clear error rather than a null-address call

Notes

Address validation cannot be shared. A single address string column that accepts both formats without validating against the chain will silently accept a mismatched pair, and the failure will surface at settlement — the most expensive place to find it.

packages/types/src/chain.ts in the Intent repo has the ChainSlug / ChainFamily split the frontend uses; matching those names keeps the API legible from both sides.

Contracts do not exist on either chain yet (see intent-core-contracts#10 and intent-stellar-contracts#4), so the routing can be built and tested before there is anything to route to.

Done when

• An intent records which chain it belongs to
• An Arc address on a Stellar intent is rejected at the API boundary
• Settlement dispatches on chain, with tests for both