feat: Update Status page to use CGW

[yagopv]

Context

We are now redirecting the Transaction Service public endpoint to the new api.safe.global, which has some implications for rate limiting. We decided to start using CGW instead because we can use to have broader limits.

How this PR solve the issue ?

This pull request introduces several improvements and refactors to the application's configuration handling, API polling, and UI styling. The most significant changes are the switch to using the Client Gateway URL for chain status queries, the introduction of a rate-limited polling manager for API calls, and updates to the UI for a more modern look and improved performance.

✨ Key change: We are making one request every 200 ms (within a 5 RPS range) and one loop of requests every 30 seconds

Configuration and API Refactoring:

• The application now uses VITE_CLIENT_GATEWAY_URL instead of the previous config service URL and removes the config service selector, simplifying environment configuration and chain status fetching.
• The API for fetching chain status (getChainStatus) is refactored to use the client gateway endpoint and chain ID, aligning with the new configuration approach.

API Polling Improvements:

• A new PollingManager utility is introduced to manage rate-limited polling for API calls, preventing excessive requests and improving performance. The useApi hook is refactored to leverage this manager for all polling tasks.

UI and Styling Updates:

• The font is updated to "DM Sans" from Google Fonts, and the color palette is adjusted for a darker primary color. The app logo is resized and its animation removed for a cleaner header.
• The app title and its styling are removed from the header for a more streamlined appearance.

Polling Interval Adjustment:

• The chain status polling interval is increased from 5 seconds to 30 seconds to reduce load and align with the new rate-limited polling strategy.

---

Note

Switches chain status queries to Client Gateway with centralized rate-limited polling and updates UI/fonts/logo and env configuration.

• API & Data fetching:
  • Replace Transaction Service endpoint with Client Gateway: getChainStatus(clientGatewayUrl, chain) -> GET /v1/chains/{chainId}/about/indexing.
  • Pass clientGatewayUrl through App -> ChainStatusTable -> ChainStatusRow.
• Polling & Performance:
  • Introduce PollingManager with ~5 RPS limit, visibility-aware pausing, and managed aborts.
  • Refactor useApi to use PollingManager; add task lifecycle management.
  • Increase chain status polling interval to 60_000ms.
• Config:
  • Add VITE_CLIENT_GATEWAY_URL; keep VITE_CONFIG_SERVICE_URL; remove config service selector usage.
  • Update example.env accordingly.
• UI/Theme:
  • Add DM Sans font (public/fonts/fonts.css) and set as default typography; adjust primary color.
  • Update header: new SVG logo, smaller size, remove title/animation, add invert filter.
  • Include fonts in index.html.
• Misc:
  • Bump version to 0.5.0.

^{Written by Cursor Bugbot for commit 9e0e27b. This will update automatically on new commits. Configure here.}

[cursor]

This is the final PR Bugbot will review for you during this billing cycle

Your free Bugbot reviews will reset on November 29

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[cursor]

Bug: Drifted Timing After Rate-Limit Delay Resets

Race condition: After waiting for rate limiting delay, the code updates lastRequestTime and lastExecuted to Date.now() instead of the original 'now' timestamp from before the delay. This causes timing drift - if the delay is 200ms, the next task will be scheduled 200ms later than intended, compounding over time and reducing effective polling rate.