fix(cursor): prefer enterprise auth and handle missing limits

[drewwells]

This change fixes a multi-account Cursor edge case by preferring
keychain auth when SQLite indicates a free account and the token
subjects differ, ensuring enterprise usage is attributed to the
correct account. It also handles percent-only usage payloads when
planUsage.limit is missing, avoiding false errors while still
rendering valid usage lines.

Regression tests were added for both auth-source selection and
missing-limit percent usage.

Description

Related Issue

Type of Change

• Bug fix
• New feature
• New provider plugin
• Documentation
• Performance improvement
• Other (describe below)

Testing

• I ran bun run build and it succeeded
• I ran bun run test and all tests pass
• I tested the change locally with bun tauri dev

Screenshots

Checklist

• I read CONTRIBUTING.md
• My PR targets the main branch
• I did not introduce new dependencies without justification

---

Summary by cubic

Fixes a multi-account auth edge case by preferring keychain tokens when SQLite looks Free and JWT subjects differ, so enterprise usage is attributed to the right account. Also handles Connect usage responses that omit planUsage.limit by using percent-only data when available and only falling back to request-based metrics when needed (e.g., Enterprise/Team).

• Bug Fixes
  • Prefer keychain auth when SQLite shows "free" and JWT subjects differ.
  • When planUsage.limit is missing: render percent usage if totalPercentUsed exists; otherwise fall back to REST request-based usage (Enterprise/Team or when plan info is unavailable).
  • Add regression tests for auth selection, percent-only handling, and enterprise missing-limit fallback.

^{Written for commit cbb7b08. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="plugins/cursor/plugin.js">

<violation number="1" location="plugins/cursor/plugin.js:505">
P2: Percent-only usage can still fail when plan info is unavailable because the new fallback triggers on missing limit before percent-based rendering.</violation>
</file>

---

Since this is your first cubic review, here's how it works:

• cubic automatically reviews your code and comments on bugs and improvements
• Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
• Add one-off context when rerunning by tagging @cubic-dev-ai with guidance or docs links (including llms.txt)
• Ask questions if you need clarification on any suggestion

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

1 issue found across 2 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="plugins/cursor/plugin.js">

<violation number="1" location="plugins/cursor/plugin.js:506">
P2: Added `!hasTotalUsagePercent` can skip unknown-plan REST fallback and cause hard failure for team-inferred accounts missing `planUsage.limit`.</violation>
</file>

_{Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.}

[cubic-dev-ai]

P2: Added !hasTotalUsagePercent can skip unknown-plan REST fallback and cause hard failure for team-inferred accounts missing planUsage.limit.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At plugins/cursor/plugin.js, line 506:

<comment>Added `!hasTotalUsagePercent` can skip unknown-plan REST fallback and cause hard failure for team-inferred accounts missing `planUsage.limit`.</comment>

<file context>
@@ -503,6 +503,7 @@
 
     const needsFallbackWithoutPlanInfo = usage.enabled !== false &&
       (!hasPlanUsage || planUsageLimitMissing) &&
+      !hasTotalUsagePercent &&
       !normalizedPlanName &&
       planInfoUnavailable
</file context>

[drewwells]

I'm not sure how important this is... it seems like overengineering. We will not catch all edge cases, but I don't believe this adds a new error