fix(sdk): warn when embedded request is dropped for exceeding link limit (#584)

[chiliec]

What

Closes #584.

BridgeProvider drops the embedded request and regenerates a connect-only universal link whenever the link exceeds the 1024-character cap (packages/sdk/src/provider/bridge/bridge-provider.ts). As #584 notes, ordinary payloads (a connect request with ton_proof + two jetton transfers measures 1066 chars) cross that threshold, so "connect and pay in one tap" quietly becomes two steps — and the dApp only sees dispatched: false with no indication that the link size was the reason.

Fix

This PR addresses the two concrete, non-behavioural points raised in the issue. It intentionally does not change the 1024 threshold or the wire encoding — whether the budget should grow (or the encoding shrink) is a design decision left to the maintainers, as the issue asks.

1. Make the drop observable. When the embedded request is dropped for length, BridgeProvider now emits a logWarning (using the SDK's existing logger) explaining that the link exceeded the limit and the embedded request will not be dispatched. The warning only fires when a request actually carried an embedded payload; connect-only links are unaffected. No behaviour changes — the same connect-only link is still returned.

2. Centralise the magic number. The issue notes that 1024 was written out separately in bridge-provider.ts, in packages/ui/src/app/utils/web-api.ts as MAX_LINK_LENGTH, and in the SDK test, "with nothing tying them together" (both source sites even carry a comment asking for this). This PR introduces a single exported MAX_UNIVERSAL_LINK_LENGTH constant in the SDK and reuses it from all three places, so the values cannot drift apart. MAX_LINK_LENGTH is kept as a re-export for backwards compatibility.

Tests

• The existing universal-link.test.ts now imports the shared constant instead of re-declaring 1024, plus a new assertion that pins MAX_UNIVERSAL_LINK_LENGTH === 1024.
• Verified genuine RED→GREEN: temporarily changing the shared constant to 2048 turns exactly the drift-sensitive tests red (the new assertion + the exceedsMaxUrlLength boundary cases); restoring to 1024 returns all green — proving the test actually locks the value.

Validation (real results, Node 22.19, pnpm 10.14)

• vitest run (full SDK suite): 183 passed (8 files)
• turbo run build --filter=@tonconnect/sdk: success (tsc + api-extractor + webpack)
• turbo run build --filter=@tonconnect/ui: success (typechecks the cross-package MAX_UNIVERSAL_LINK_LENGTH import)
• prettier --check and eslint on all changed files: clean

First-time contributor here — happy to adjust the wording of the warning, the bump levels in the changeset, or the constant's name/location if you'd prefer them elsewhere.

[vercel]

@chiliec is attempting to deploy a commit to the TOP Innovations Ltd Team on Vercel.

A member of the Team first needs to authorize it.