Fix skip token-usage API calls in OSS mode — fetch only in cloud

[Deepak-Gnanasekar]

##What

Removes getTokenUsage from the OSS codebase and makes it a cloud-only optional import. The token-usage API is no longer called in OSS mode.

Files changed:

• frontend/src/ide/chat-ai/services.js — Removed getTokenUsage function and its export
• frontend/src/ide/chat-ai/ExistingChat.jsx — Replaced service hook usage with optional try/require import from cloud plugin; added isCloud guard
• backend/.../message_views.py — Reverted OSS-mode fallback; token_data is None now returns 500 since this endpoint is never reached in OSS

##Why

The getTokenUsage function calls a token-usage API backed by the subscriptions module, which only exists in cloud. Having it in the OSS service layer caused:

1. Unnecessary API calls in OSS that always failed or returned meaningless zeroed-out data
2. A workaround 200 response with token_tracking_available: false in the backend to mask the missing module — hiding the real error
3. Cloud-specific business logic leaking into the OSS codebase

This aligns getTokenUsage with the existing pattern used for other cloud-only features (fetchOrganizationTokenBalance, getTokenBalance, TokenTopupDrawer) —
optional try { require(...) } catch {} imports that resolve to null in OSS.

##How

Frontend:

1. Removed getTokenUsage from useChatAIService() in services.js
2. Added optional import at the top of ExistingChat.jsx:
   let getTokenUsage = null;
   try {
   ({ getTokenUsage } = require("../../plugins/token-management/token-usage"));
   } catch {
   // OSS: token usage API not available
   }
3. Added isCloud session check via useSessionStore
4. Guarded the call site with if (getTokenUsage && isCloud && updatedData.length > 0) — triple check ensures the block only runs when the plugin exists AND we're
   in cloud mode AND there are messages to fetch

Backend:
5. Reverted message_views.py — removed the fake 200 fallback response for token_data is None and restored the proper 500 error. This endpoint is now only called
from cloud, so the OSS workaround is unnecessary.

##Can this PR break any existing features?

OSS: No. The token-usage API call is completely skipped. Previously it was called and silently returned zeroed data with token_tracking_available: false —
removing it has no user-visible impact.

Cloud: No, provided the companion cloud PR (adding plugins/token-management/token-usage.js) is merged first or simultaneously. If the cloud plugin is temporarily
missing, the try/catch gracefully falls back to null and token usage simply doesn't load — no crash, no error.

##Dependencies

• Cloud repo: Companion PR adds plugins/token-management/token-usage.js — should be merged before or alongside this PR

##Testing

• OSS build succeeds — no import errors
• OSS: open a historical chat conversation — no token-usage API calls in network tab
• Cloud: open a historical chat conversation — token usage data loads correctly per message
• Cloud: verify no regression in token usage display for new messages (WebSocket path unchanged)

Checklist

I have read and understood the Contribution Guidelines.

[tahierhussain]

LGTM

[wicky-zipstack]

LGTM