Initial import: eCW Charge Validation bot and results Portal

Snapshot of the working project as of 2026-10-23 (local 2d4d4fc), one
commit with no earlier history: the tracked files were de-identified
first (synthetic claim ids and patient data only; see Context.md
section 7). Credentials, run logs, screenshots, claim reports and client
workbooks are gitignored and not included.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/adr/0001-run-events-in-files.md

@@ -0,0 +1,25 @@
+# Run events go to a file per Run, not to SQL
+
+Every Run writes its events (eCW Login Attempt steps, Run Errors, Claim
+Errors, Warnings, each with its time) to `Logs\events_<run>.jsonl`, and the
+Portal's Runs page reads those files — while the Charge Summary rows, Portal
+Users and Sign-in history live in SQL Server (`Charge_Validation`). We chose
+files because the events matter most exactly when things go wrong: during
+the eCW login (before the database is touched at all), when SQL Server is
+down, and when a Run is killed or the browser crashes — a line flushed to a
+file survives all of those, the same way `Logs\run_<ts>.log` already does.
+
+## Considered Options
+
+- **SQL table (`CV_RunEvent`)**: easier filtering across months, but a Run
+  with no database would lose its own failure record, and the bot's results
+  write is deliberately never fatal — events would inherit that "maybe".
+- **Parse the existing run logs**: no bot change, but the log lines carry
+  no time, so login durations and error times could not be shown.
+
+## Consequences
+
+- The Runs page reads one small file per Run; if that ever gets slow, load
+  the files into SQL as a copy, keeping the files as the source.
+- Portal Users and Sign-ins are in SQL because the Portal already needs SQL
+  for its results; a Portal with no database shows nothing either way.