[Bug] Bonus token claims fail with 'The result could not be confirmed' when subscription is near expiration

[romangalaxys10-spec]

Bug Description

When users attempt to claim promotional or compensation bonus token packages (such as the 300M Weekend Build or 100M Trust Build), the claim flow consistently fails with an error modal:

"The result could not be confirmed. Check your benefits later. This action will not be retried this session to avoid duplicate submissions."

---

Source & Attribution

• Reporter / Credit: Discord user @Anchorite
• Thread Reference: Discord #coding-plan Thread 1553976733940580352
• Reported Context: User previously claimed weekend builds successfully earlier in the month, but now reproduces this failure consistently across both the 300M weekend bonus and the 100M Trust Build bonus.

---

Reproduction & Root Cause Hypothesis

1. Near-Expiration Entitlement Guard Conflict:

   • The user's paid subscription is scheduled to expire within ~24-48 hours (Tuesday).
   • The backend bonus provisioning service appears to perform an entitlement validity check comparing the remaining active subscription duration against the bonus package's lifespan.
   • When the remaining subscription duration is shorter than the bonus validity window (or when the account enters a pending-expiration state), the quota ledger transaction fails or is rejected upstream.

2. Client State Handling:

   • Rather than returning a clear explanatory validation message (e.g., "Requires active plan valid through bonus duration" or granting the bonus independently of subscription end-date), the backend returns an unconfirmed/error state.
   • The client then triggers its idempotent anti-duplication modal: "The result could not be confirmed. Check your benefits later. This action will not be retried this session to avoid duplicate submissions."

---

Expected Behavior

• Bonus token claims should either:
  1. Grant successfully regardless of the active subscription's exact remaining days (pro-rating or expiring the bonus independently), or
  2. Return a specific, actionable error message explaining why the claim cannot be completed, rather than a generic unconfirmed state that locks out retries for the session.

---

Steps to Reproduce

1. Have an account whose paid subscription is within 1-2 days of expiration.
2. Open ZCode / Web Console and attempt to claim the 300M Weekend Build or 100M Trust Build bonus.
3. Observe the popup modal stating "The result could not be confirmed..." and no quota credited to the account ledger.

[github-actions]

👋 感谢你的反馈，我们已经收到。

• 维护者看到后会尽快回复你。
• 状态保持为 status: 待评估，你可以随时补充信息。
• 信息不全时我们会打上 needs: 更多信息 标签并 @ 你。

---

👋 Thanks — we've received your issue.

• A maintainer will get back to you as soon as we can.
• Status stays at status: 待评估 (Triage); feel free to add context.
• If we need more details, we'll add needs: 更多信息 and ping you.

[0-danielviktorovich-0]

Same here — claim of the giveaway tokens fails server-side for my account (claimManualPlan FAIL — coding_plan_system_busy, fast 300–700 ms rejections, no timeout), active Coding Plan subscription, macOS ZCode 3.14.4. Full log evidence and request-ids in my comment on #873 (account ID shared privately with the team via email).

One extra data point for your expiry hypothesis: at the same time my desktop app's plan view fails to load at all (getCodingPlanResetStatus — coding_plan_reset_api_error:3101 continuously), while the web version works fine — so whatever server-side state is involved, it breaks both the claim and the plan-status endpoint for this account.

[paolo-psq]

Same here for the 100M claim.
Coding Plan renewal is the 30th October. Apple M1 latest macOS Tahoe , zCode 3.14.4.
zCode logs: server-side error: coding_plan_system_busy.