Integrate InviteSDK rewards flow into citizen claim widget

[Copilot]

Adds @goodsdks/invite-sdk@1.0.1 to the citizen claim widget and replaces the Invite Rewards placeholder with a provider-first, viem-backed invite lifecycle. Claim and Invite Rewards now share invite validation, joining, and refresh state without changing claim behavior.

• Shared invite runtime

  • Initializes InviteSDK only for Celo/XDC and delegates reads, simulations, writes, error mapping, and collection to the SDK.
  • Loads invite user, level, invitees, pending invitees, and eligibility diagnostics.
  • Supports retryable loading, unsupported-network, disconnected, join, collection, and mutation-error states.

• Invite code and joining

  • Implements GoodWallet’s Base58 shortest-unused-prefix algorithm using InviteSDK.resolveCode.
  • Validates unknown, self, and already-joined invite codes before joining.
  • Exposes the same pending-safe join action from both Claim and Invite Rewards.

• Rewards experience

  • Adds reward education, verified-code creation, current-page sharing, pending/approved invitee status, diagnostics, and batch collection.
  • Shares the exact current page URL without host callback, route, or destination configuration.

const message =
  `Claim GoodDollar with me. Open this page and use my invite code: ${code}\n` +
  window.location.href

• Coverage and documentation
  • Adds Invite Rewards tab smoke coverage and updated screenshot evidence.
  • Documents supported networks, environment behavior, sharing contract, code generation, and collection lifecycle.

[L03TJ3]

@copilot

Please update the direct dependency to @goodsdks/invite-sdk@1.0.3 and refresh pnpm-lock.yaml.

Then wire only these two SDK capabilities. No broader Invite Rewards redesign, copy pass, or documentation work is needed in this follow-up.

1. Deferred inviter attachment

The contract and InviteSDK 1.0.3 support this valid flow:

await sdk.join(myCode, zeroHash)     // personal code was registered earlier
await sdk.join(myCode, inviterCode)  // attach one valid inviter later

Update the widget so a user who already has user.inviteCode may still enter an inviter code when:

user.inviteCode !== zeroHash &&
user.invitedBy === zeroAddress &&
!user.bountyPaid

Use the existing user.inviteCode as myCode in sdk.join; only run generateInviteCode for a user with no code yet. Remove the widget-level joinedAt > 0n rejection and change the join-card visibility predicate to the rule above. Keep the SDK typed errors as the final guard.

Important protocol boundary: an ordinary UBI claim does not prevent this. A paid invite bounty or an already attached inviter does; show the normal SDK error in those cases.

2. Pending invitees that can be collected

Use the new SDK helper in 1.0.3:

const collectableInvitees = await sdk.getCollectableInvitees(address)

Keep getPendingInvitees(address) for showing the full pending-address list. Store collectableInvitees in the invite runtime and enable "Collect eligible rewards" only when that array is non-empty. actions.collectAll can continue to call sdk.collectAllBounties(); the contract already safely skips pending invitees that are not eligible.

This replaces the current details.isActive check, which is not an eligibility check. Do not add per-invitee diagnostic logic beyond what is already present.

Please add focused tests for:

• a code-only registered user attaching a valid inviter later, using the original code;
• a paid/already-attached user not seeing or completing that flow;
• collect enabled only when getCollectableInvitees is non-empty.

[Copilot]

@copilot

Please update the direct dependency to @goodsdks/invite-sdk@1.0.3 and refresh pnpm-lock.yaml....

Addressed in 573f1c1: upgraded to InviteSDK 1.0.3, reuses registered codes for deferred inviter attachment, gates collection through getCollectableInvitees, and adds focused coverage.