feat: add SetupAgreement list to SetupAction for document consent (ORD-1856)

[aaronmboyd]

Closes ORD-1856
Linear: https://linear.app/lifi-linear/issue/ORD-1856

Intent

This PR adds the SetupAgreement type and an optional agreements list on SetupAction. The change is type-only. getProviders already returns the /providers body as it is, so no runtime code changes.

What changed

• packages/perps-types/src/providers.ts: the new exported interface SetupAgreement { title; url }. SetupAction gets agreements?: SetupAgreement[]. Its TSDoc states the UI contract: one link and one checkbox per entry, and the step executes only after the user accepts all entries. ProviderAction and docsUrl do not change.
• .changeset/ord-1856.md: a minor bump for @lifi/perps-types and @lifi/perps-sdk. @lifi/perps-sdk re-exports perps-types through export * from '@lifi/perps-types'. No provider package re-exports perps-types.

Assumptions

None. The field is fully general. The SDK holds no Ondo URLs, because the backend owns the copy (ORD-2056).

Tests

• packages/perps-types/src/providers.unit.spec.ts (edited): new compile-time assertions _SetupAgreementKeys (exactly title and url), _SetupAgreementsShape (SetupAgreement[] | undefined) and _SetupAgreementsIsOptional. The existing _ProviderActionKeys assertion still passes, which shows that ProviderAction does not get the field.
• packages/perps-types/src/index.unit.spec.ts (edited): new case exports SetupAgreement. It checks that the index type equals the providers.ts type.
• packages/perps-sdk/src/services/getProviders.unit.spec.ts (edited): new case passes setup agreements through unchanged. An MSW /providers fixture with two agreements reaches the caller with the same value.

Gates: pnpm check, pnpm check:types, pnpm check:types:spec, pnpm build and pnpm test:unit pass.

Follow-ups

(none). The chain issues already exist: ORD-2056 (backend), ORD-2057 (widget) and ORD-2058 (docs).

Dependencies / upstream branches

No upstream branches. This PR blocks ORD-2056. A human runs the release after the merge, so that the backend can consume the new @lifi/perps-types minor version.

[github-actions]

📦 Preview published under the preview dist-tag.

Install the exact version(s) — @preview moves with the newest preview across PRs:

npm i @lifi/perps-sdk@0.0.0-preview-2ac7198
npm i @lifi/perps-types@0.0.0-preview-2ac7198

[lifi-qa-agent]

QA Review: ORD-1856 — #618

Verdict: ✅ Approve · Critical 0 · High 0 · Medium 0 · Low 0 · Awaiting response 0
Head 2ac71981 · First review · Focused direct pass (route: focused-high-risk, 1 production file)

Summary

Type-only change. Adds exported SetupAgreement { title; url } and optional SetupAction.agreements?: SetupAgreement[] in @lifi/perps-types. ProviderAction is unchanged, so Provider.actions entries do not gain the field. Changeset is a minor bump for @lifi/perps-types and @lifi/perps-sdk.

Findings

None.

Checked:

• The new field is optional and additive, so existing consumers still compile. A minor bump is right.
• index.ts re-exports providers.ts, and the spec asserts the index type equals the providers.ts type.
• Type assertions cover the exact keys, the optional shape, and the optionality of agreements.
• The getProviders spec uses an MSW fixture to show the /providers body reaches the caller unchanged. No runtime code changed.

Notes (🔵, not findings)

• Checks at head: checks, Aikido and the preview release are green. I did not re-run the local gates.
• The UI contract (one checkbox per agreement, execute only after all are accepted) is TSDoc only. Enforcement belongs to the widget (ORD-2057).
• The backend and docs follow-ups (ORD-2056, ORD-2058) depend on the release after merge.

[lifi-qa-agent]

QA review: Approve. Type-only additive change, no gating findings. Details in the QA report comment.