Standardize status/error UX and API request structure (Step 3 & 4)

[rad1092]

Motivation

• Unify status and error UX so analysis, model runs, multi-analyze and dashboard flows show consistent short user errors and optional detailed error details.
• Prevent duplicate user actions during async work by disabling controls while requests are in-flight.
• Centralize API error shape and client-side error handling so frontend can rely on a stable error + error_detail JSON format.

Description

• Frontend refactor: reorganized bitnet_tools/ui/app.js into clear concerns and introduced a common fetch wrapper postJson, a busy toggle toggleBusy, and unified error UI helpers showError/clearError to propagate userMessage + detail to the UI.
• UI changes: added intent input and intentActions region, a modeGuide area, an error display area with collapsible details in bitnet_tools/ui/index.html, and corresponding styles in bitnet_tools/ui/styles.css.
• Multi/analyze/model flows updated to use postJson and toggleBusy, and status messages were centralized in the STATUS constant to standardize displayed status strings.
• Backend changes: added Handler._error_payload helper in bitnet_tools/web.py and updated POST/GET error returns to emit { "error": <msg>, "error_detail": <detail> } so client and server share a stable error contract.

Testing

• Ran unit tests with pytest -q and all tests passed (26 passed).
• Launched the UI server with python -m bitnet_tools.cli ui --host 0.0.0.0 --port 8765 and executed an automated Playwright smoke script that exercised the intent input and captured a screenshot at artifacts/ui-step3-4-standardized.png, which validated the new status/error UI and intent-action behavior.

---

Codex Task