SDK: update useAccountUpdateRecovery to use AuthContextV2 adapter

[sentry]

This PR fixes the "Error: [SDK][Accounts] – missing keychain broadcaster" that occurred when attempting to update a recovery account using Keychain.

Root Cause:
The useAccountUpdateRecovery mutation in the SDK was expecting an AuthContext object with a direct broadcast method for Keychain operations. However, the getSdkAuthContext utility in the web app provides an AuthContextV2 object, which uses an adapter property containing broadcastWithKeychain.

This mismatch led to auth?.broadcast being undefined, causing the error.

Solution:
Updated packages/sdk/src/modules/accounts/mutations/use-account-update-recovery.ts to:

1. Change the auth parameter type from AuthContext to AuthContextV2.
2. Modify the Keychain signing logic to check for and use auth.adapter.broadcastWithKeychain instead of the deprecated auth.broadcast.

This aligns the useAccountUpdateRecovery mutation with the modern AuthContextV2 interface used across other SDK mutations, ensuring Keychain operations function correctly.

Fixes ECENCY-NEXT-13WV

[feruzm]

Reviewed this and pushed b0cc09e to the same branch, extending it to the other three instances.

The original fix is correct. I checked the parts that could be wrong: data is guarded before data.name is read, the argument order matches use-broadcast-mutation.ts:164, and owner authority is genuinely supported by the web adapter (MetaMask passes it through, the extension layer accepts it, and Keychain Mobile deep links throw a clear error rather than failing quietly).

It closed one of four. The same auth?.broadcast pattern exists in three more places, and the web app reaches all of them with an AuthContextV2 from getSdkAuthContext:

• useAccountRevokePosting, from manage-authorities.tsx:45. Identical hard throw, on the same permissions page as the reported bug.
• useSignOperationByKeychain, from transaction-signer.tsx:42. Identical hard throw.
• broadcastJson, from follow-controls.tsx:49. Different shape: there auth.broadcast is the first branch of a fallback chain rather than a requirement, so a Keychain user with a HiveSigner token still worked, and one without a stored posting key and no token reached cannot broadcast w/o posting key or token.

Why nothing caught them. Every field on AuthContext is optional, broadcast? included, so AuthContextV2 satisfies it structurally. The type checker sees no error at any call site and auth?.broadcast is silently undefined at runtime. That is why this surfaced as a Sentry issue rather than a build failure, and why fixing one site said nothing about the others.

One deliberate asymmetry. broadcastJson gets its adapter branch last, not first. Every branch above it already serves the sessions that reach it, and reordering would change which method signs for users it currently works for. Placed last, it only claims cases that were previously errors.

Left alone on purpose: the two auth.broadcast checks in use-broadcast-mutation.ts sit under case 'custom', where an explicitly supplied broadcaster is the entire point.

Verified: SDK 678 tests pass, and the web app typechecks clean against the changed signatures, which is the check that matters since all four callers are in apps/web.

Worth a follow-up once callers stop passing V1: AuthContext.broadcast would then have no users left and could be removed, which turns the next occurrence of this into a compile error rather than a runtime one.