fix(ui): handle indexing errors in frontend and enable dev mode API hosting

[sahil-mangla]

Surface indexing failures in UI and enable backend API startup in development mode

What does this PR do?

This PR addresses a poor user experience when indexing fails, particularly for extremely large repositories that may exhaust available memory.

Changes

• Fixed the frontend to render a visible error banner when an indexing job fails (status === "error") instead of silently dismissing the progress indicator.
• Preserved the existing success flow for completed indexing jobs.
• Allowed the backend HTTP server to start API endpoints in development mode even when no frontend assets are embedded, improving the local development workflow.

Why is this needed?

During investigation of issue #524, I reproduced indexing failures using a synthetic repository containing approximately 200,000 Python files.

The indexing subprocess was terminated by the OS with exit code 137 (SIGKILL / out-of-memory condition). The backend correctly transitioned the job status to "error".

However, the frontend previously treated any non-"indexing" state as completion:

if (data.length > 0 &&
data.every((j) => j.status !== "indexing")) {
onDone();
}

As a result:

1. The indexing spinner disappeared.
2. No database was generated.
3. The project did not appear in the UI.
4. No error message was shown to the user.

This made indexing failures appear as if indexing had silently completed or hung.

This PR surfaces those failures directly in the UI so users receive immediate feedback when indexing fails.

Reproduction

1. Start the UI and backend.
2. Index a very large repository (or a synthetic repository with ~200k files).
3. Force the indexer to fail (for example via OOM conditions).
4. Observe that the UI now displays an error banner instead of silently dismissing the indexing job.

Testing

Manual testing performed

• Indexed the following repositories successfully:
  • psf/requests
  • pallets/flask
  • tiangolo/fastapi
  • django/django
  • home-assistant/core
  • pytorch/pytorch

Verified that:

• Successful indexing still dismisses the spinner as expected.
• Failed indexing jobs now surface an error message in the UI.
• Development mode API endpoints continue to function when frontend assets are not embedded.

Checklist

• Every commit is signed off (git commit -s)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test

[sahil-mangla]

Linter Fix (clang-format): The second force-push was made to wrap a long string literal in src/main.c that exceeded the maximum line length check, which was causing the CI formatting job (lint-format) to fail. No logic changes were introduced.

[sahil-mangla]

Hey @DeusData shall i close the PR or should i wait for you to merge it first?

[DeusData]

Hey @sahil-mangla, a bit of patience please. At the moment there is a lot of "background work" happening. Coming back to you ASAP :)

[DeusData]

Thanks @sahil-mangla — the UI error-banner half is good and we'd like it.

The blocker is the src/main.c change: it removes the CBM_EMBEDDED_FILE_COUNT > 0 guard, so the HTTP server now starts whenever --ui is set, even in the standard binary with no embedded assets. The server binds loopback only (so it's local-only, not a network exposure), but it still turns a documented no-op into a live listener — a behavior-contract change.

Could you split this PR: keep the UI error-handling, and gate the always-start-server behavior behind an explicit opt-in (e.g. a --dev-api flag) rather than removing the asset guard? The UI half can merge as soon as it's separated. 🙏

[sahil-mangla]

@DeusData
Thanks for the review and for clarifying the concern.

I agree that removing the CBM_EMBEDDED_FILE_COUNT > 0 guard changes the existing behavior contract for --ui, even if the listener is loopback-only.

I’ll split the changes and update this PR to keep only the UI error-handling improvements. I’ll revert the src/main.c change from this PR and keep the development-server behavior as a separate follow-up, potentially behind an explicit opt-in flag such as --dev-api.

[DeusData]

Thanks @sahil-mangla — the StatsTab.tsx error-banner fix itself is good and we'd like it. But the PR currently contains 709 changed files / +3022 lines: ~706 are graph-ui/.npm-cache-local/ npm-cache blobs that got committed, plus scratch/generate_stress_repo.py (which is gitignored and shouldn't be pushed) and some unrelated package-lock.json churn.

Could you reduce this to just the StatsTab.tsx change — remove the .npm-cache-local/ tree and the scratch script, add graph-ui/.npm-cache-local/ to .gitignore so it can't recur, and drop the lock-file churn? Once it's down to the single file, it's good to go. 🙏