Add cook data logging foundation (SQLite history + sessions API)

[CamSoper]

Why

Inferno has strong real-time control (PID hold, fire health/reignition, lid detection, preheat) but nothing was persisted — temps and mode transitions lived in memory and were lost on every inferno-api restart. This PR adds a cook-data logging/persistence layer: the foundation for the features most likely to come next (probe target alarms, done-time/stall prediction, cook history & graphs, CSV export).

The LLM "pitmaster" advisor discussed during planning is intentionally deferred — this is the data foundation only.

What

• SqliteCookLogStore (Microsoft.Data.Sqlite) — single long-lived connection; journal_mode=WAL + synchronous=NORMAL and batched transactions to minimize SD-card fsyncs; schema applied idempotently on init. A lock serializes access across the logger loop and request threads.
• CookLogger — background sampling loop mirroring the existing DisplayUpdater/FireMinder pattern. Polls ISmoker.Status ~every 10s and infers cook-session boundaries from mode transitions, so it never touches the safety-critical state machine. Opens a session on entry to a cooking mode, keeps it through the Shutdown cooldown, closes on return to Ready. Resumes an in-progress session (or closes an orphan) after a restart.
• SessionsController — GET /api/sessions, GET /api/sessions/active, GET /api/sessions/{id}?from=&to=, GET /api/sessions/{id}/export.csv, POST /api/sessions/{id}/label.
• Program.cs — store + logger registered as singletons; teardown order on ApplicationStopping is logger → smoker → store → gpio so logging flushes before the smoker tears down.
• Inferno.Deploy — creates ~/inferno/data on the Pi (outside the publish dirs the deploy replaces, so history survives upgrades) before the api service starts.

Schema

cook_session (id, start/end time, label, peak grill/probe temp, sample_count) and sample (session_id, timestamp, grill/probe temp, mode, setpoint, pvalue, auger/blower/igniter/fire_healthy/preheated), indexed on (session_id, timestamp). v1 omits a discrete event table — per-sample mode reconstructs transitions at 10s resolution.

Testing

• dotnet build Inferno.sln ✅   dotnet test Inferno.Tests ✅ (90 passing; 28 new)
• New tests exercise the full store + logger path against a real (in-memory) SQLite DB: session open/close on mode transitions, no double-open across Smoke↔Hold↔Sear, startup resume/orphan handling, status→sample field mapping, batch-flush threshold, force-close + flush on dispose, and peak tracking.
• The API process itself initializes GPIO/SPI on startup (Pi-only), so it isn't run off-device here — the new code path has no hardware dependency and is covered directly by tests. On-device verification (drive /api/mode, then GET /api/sessions* and the CSV export; restart mid-cook) is listed in the plan.

🤖 Generated with Claude Code

https://claude.ai/code/session_018HrUqCycauyXrhgs3o6KtN

---

Generated by Claude Code

[pulumi]

🚀 The Update (preview) for CamSoper-org/inferno-deploy/main (at 30df637) was successful.

✨ Neo Code Review

Routine feature deployment adding cook history logging via SQLite. The API rebuild and service restart are expected; the new `ensure-data-dir` step safely pre-creates the data directory. ✅ Low Risk

This PR adds cook session history: a SQLite-backed store, a background polling logger, and REST endpoints for listing/exporting sessions. The infrastructure changes are driven by two things: the API source hash changed (new files/dependencies), triggering the publish-api and restart-api replacements, and the new ensure-data-dir step was added to pre-create ~/inferno/data/ on the Pi before the service starts.

🔵 Info — The ensure-data-dir step runs mkdir -p to create the DB directory outside the publish path, meaning cook history will survive future deployments. The restart-api replacement depends on it, so the service won't start until the directory exists. The DB path defaults to ~/inferno/data/inferno.db but can be overridden via INFERNO_DB_PATH.

🔵 Info — On first deploy, the API will create a fresh SQLite database. If the smoker happens to be mid-cook when the service restarts, CookLogger.ResumeOrReset() will detect no open session in the new DB and begin fresh tracking on the next tick — no cook history will be lost from a DB that didn't previously exist, but any session open at restart time will not be retroactively recorded.

Resource Changes

    Name             Type                    Operation
+-  restart-api      command:remote:Command  replaced
+   ensure-data-dir  command:remote:Command  create
+-  publish-api      command:local:Command   replaced