feat: add session status indicator and connection badge to UI

[vrutank14t7]

Closes #143

Changes

• SessionBadge.jsx — color-coded badge (🟢 Connected / 🟡 Connecting / 🔴 Disconnected)
• useSession.js — real backend health check polling every 5 seconds
• DataContext.jsx — sessionId + connectionStatus added for future multiuser work
• main.py — /health GET endpoint added for clean connection status checks

Testing

• Badge shows 🟡 Connecting on page load
• Badge shows 🟢 Connected when backend is running
• Badge shows 🔴 Disconnected when backend is down
• Auto re-checks every 5 seconds

[Uday9909]

Thanks for adding a visible session status badge and wiring
backend health polling into the UI this improves
observability for users.

A few technical issues worth addressing before merge:

1. Hardcoded backend URL breaks non-localhost deployments

File: webapp/src/hooks/useSession.js
Location: checkConnection() fetch call

The hook calls fetch("http://127.0.0.1:10000/health")
directly. This breaks in Docker, remote dev, staging, and
any deployment where the frontend and backend are on
different hosts. The rest of the app uses a configurable
API base URL — the health check should use the same
pattern rather than a hardcoded address.

2. Client-generated session ID does not align with
backend session lifecycle

File: webapp/src/hooks/useSession.js
Location: generateId() + setSessionId(prev => prev ?? generateId())

The hook generates a random session ID on the client side
without registering it with the backend. The project
direction is moving toward backend-owned session lifecycle
where sessions are created via /create_session and
cleaned up via /end_session, with the backend owning
the mapping between session ID and GDB controller state.
A client-generated ID that is never validated server-side
will conflict with that model and give a false sense of
session isolation.

The correct approach is to call /create_session, store
the returned session ID in context, and use that as the
authoritative identity for all subsequent requests.

3. No tests for the new polling behavior or state
transitions

Files: useSession.js, SessionBadge.jsx, DataContext.jsx

Seven files changed, zero test files added. The new
behavior includes an initial "Connecting" state,
transition to "Connected" on 200 OK, transition to
"Disconnected" on failure, and periodic re-poll with
cleanup on unmount. None of these transitions are tested.

Adding hook tests with mocked fetch and fake timers would
let us verify the state machine behaves correctly under
network failures and during component unmount, which is
exactly where polling logic tends to leak.

The most critical fix is item 2 , moving from a
client-generated ID to a backend-created session before
this lands. The status badge UI itself is a useful
addition and worth keeping once the session model is
correct underneath it.

[vrutank14t7]

Thanks for the detailed review — really helpful!

You're right about the session lifecycle. I’ll update the implementation to:

• Use backend-driven session creation via /create_session
• Store and propagate the server-generated session ID instead of generating it on the client
• Replace the hardcoded health URL with the existing API base configuration

I’ll push an updated version shortly.

[vrutank14t7]

Merged session status indicator and backend-driven session handling.

• Added /create_session and /health endpoints
• Shifted session ownership to backend (UUID-based)
• Implemented connection polling with proper cleanup
• Ensured idempotent session initialization
• Added tests for hook and UI components

Verified via local testing and network inspection.