phase-4: the live tax position, deadlines and the notifications behind them

The dashboard, the deadline engine, the three sweeps and the notification
channels. Confirm a comprobante and the IVA and IRP figures move; every
headline number opens the documents behind it.

The dashboard does no arithmetic of its own: it picks inputs and calls
packages/rules. The acceptance test asserts the API's numbers equal what
computeF120 and computeF515 produce over the same rows, before and after the
bandeja is confirmed, so a drift in either direction fails.

Deadlines come from the calendario perpetuo, skipping any period earlier than
the date the taxpayer took the obligation on. Without that guard a brand new
account opens on a red overdue card for a period that predates it.

Sweeps are idempotent by dedupe key rather than bookkeeping: a restarted
poller, a second replica and a crash mid-sweep all converge on one run, and one
reminder per user per period per milestone. They queue notifications rather
than sending them, so a channel being down retries on the job schedule. The
T-10 test derives the date from dueDateFor rather than restating the calendar.

Auto-confirm only touches what the rules were confident about and never a
decision the user already made. An unconfigured channel is absent rather than
broken: the fan-out skips it, the UI hides it, and a frozen account receives
nothing.

Web: the dashboard's three zones with swipeable position cards and traceable
numbers, the deadlines timeline, and the app shell with the tab bar and the
persistent scan button FLOWS.md asks for.

Two additions to the specs, both marked: hasDocuments on DashboardDto, without
which a position of all zeros is indistinguishable from a real one and the
first-run state never shows; and an insight_dismissals table, which FLOWS.md
requires and SPEC.md has nowhere to put.

Also: pnpm db:reset, because the e2e suite changes the seed it runs against and
a suite that is not repeatable is not a suite.

280 vitest tests, 51 Playwright tests, rules coverage still 100%, typecheck and
lint clean.

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

README.md

@@ -7,9 +7,9 @@ and ready to file yourself.
 Working name. See `docs/` for the specifications, `DECISIONS.md` for choices made along the
 way and the gaps that still need answers.
 
-> **Status: phase 3 of 8.** Foundation, tax rules, identity, and ingestion: scan a QR
-> comprobante or type one in, and it is classified and waiting in the bandeja. The
-> dashboard, declarations and the admin area are still ahead.
+> **Status: phase 4 of 8.** Everything up to a live tax position: scan a comprobante,
+> confirm it, and watch the IVA and IRP figures move, with deadlines tracked and reminders
+> queued. Declarations and the admin area are still ahead.
 
 ---
 
@@ -86,6 +86,7 @@ driver, and user facing strings cannot be written inline in JSX.
 | `pnpm lint` | eslint, including the module boundary and inline copy rules |
 | `pnpm db:migrate` | Auth tables, then our migrations |
 | `pnpm db:seed` | Demo accounts and their comprobantes, idempotent |
+| `pnpm db:reset` | Drops the local SQLite file and rebuilds it. Destructive, SQLite only |
 | `pnpm --filter @impuestos/api fixtures` | Redraws the scan fixtures under `/fixtures` |
 
 ## Configuration
@@ -168,8 +169,16 @@ parity. Playwright covers the golden paths against a running stack. CI runs the
 against both SQLite and Postgres.
 
 `pnpm test:e2e` does not start anything: bring the stack up first, then point it at the
-right origin.
+right origin. The suite signs in as the demo accounts and confirms, rejects and scans
+against their data, so it changes the state it runs in. Reset before a run, with the stack
+stopped, or the second run has a different bandeja than the first:
 
 ```bash
-E2E_BASE_URL=http://localhost:3000 pnpm test:e2e
+pnpm db:reset
+```
+
+Then start the stack and run it:
+
+```bash
+E2E_BASE_URL=http://localhost:3005 pnpm test:e2e
 ```