feat: add PermitSingle to TypedDataPrimaryTypes

[chybisov]

Which Linear task is linked to this PR?

JUMADV-90 — Widget: native Permit2 (PermitSingle) signing for custom swap providers

Companion to lifinance/sdk#475. Neither PR blocks the other — see below.

Why was it implemented this way?

One line: 'PermitSingle' is appended to TypedDataPrimaryTypes.

What the type is

Permit2's AllowanceTransfer message. A custom swap provider can return one on a quote step so the user signs an allowance for the provider's own spender — a Uniswap Universal Router, for example. The API then embeds that signature into the step's calldata, and the user sends the transaction themselves.

This is distinct from the PermitWitnessTransferFrom / PermitTransferFrom family already declared here, which is Permit2 SignatureTransfer and belongs to the gasless relayer path.

Why declare it now

The type is already reachable in practice. sdk#475 classifies it today through a readonly string[] allowlist rather than a union comparison, because primaryType === 'PermitSingle' does not compile against this union — TS2367: This comparison appears to be unintentional.

That allowlist is deliberate and stays correct either way: the API can introduce a primary type before this package knows it, so the SDK's classifier has to tolerate unknown values regardless. Declaring the member here adds three things:

• the SDK can compare against the union directly, and drop the allowlist when it chooses to;
• the backend and the widget can name the type;
• the API contract is documented in the one place consumers read.

Alternative considered: also add PermitBatch

Left out on purpose. PermitBatch carries PermitDetails[] across several tokens, while the consuming allowance path in the SDK is single-token — it reads step.action.fromToken.address. Declaring PermitBatch would suggest support that does not exist. It currently falls to the SDK's default classification, which routes it to the relayer and is the safe answer.

Placement

Appended to the end of the array, matching how NonceMapping (#502) and HyperliquidTransaction:ApproveBuilderFee (#505) were added.

Commit type

feat: rather than the chore: used by those two PRs. This is an API-surface addition that a consumer will pin against, so it should cut a minor and appear in the changelog.

Visual showcase (Screenshots or Videos)

Not applicable — a type declaration.

Compatibility

Additive and non-breaking. TypedDataPrimaryType is a union of string literals; widening it cannot invalidate existing code that produces those values.

One note for consumers that consume the union: an exhaustive switch or lookup over TypedDataPrimaryTypes will now see a member it did not before. In the SDK this is intentional and already handled — its lane table asserts an entry exists for every declared primary type, and PermitSingle is already mapped, so the suite stays green after the pin is bumped.

Verification

• pnpm typecheck — clean.
• pnpm build — clean; the emitted declaration carries the new member.

Checklist before requesting a review

• I have performed a self-review and testing of my code.
• This pull request is focused and addresses a single problem.
• If this PR modifies the Types API or adds new features that require documentation, I have updated the documentation in the public-docs repository.

The third item is unchecked deliberately: this declares a type the API can already emit, and public-docs has no page enumerating typed-data primary types. Point me at one if I have missed it and I will update it.