fix(backend): restore the declared wire types in database.ts (closes #251)

[dchaudhari7177]

Scope: QUAL-3 only. The ModuleId canonicalisation divergence (ARCH-3) in the same issue spans contracts and both Python copies and is deliberately not touched here.

The defect

fetchAndAssemble declared ApiDailyProgressResponse / ApiNestResponse and then threw them away:

progressData.progress.forEach((p: any) => {   // :277
nestsData.nests.forEach((n: any) => {         // :296

Those were the only two : any in backend/src. Removing the annotations is sufficient — backend/tsconfig.json sets "strict": true, so TS infers DailyProgress / NestData. tsc --noEmit passes.

The contract test chapter 11 asked for

The chapter-11 entry "Backend database.ts reading typod field names" prescribes "Add a contract test that reads a known row and checks the field values". That was never done. backend/tests/database-progress-contract.test.ts does it — 6 cases, stubbing duckdb-service with known rows and asserting by value, because a typod read yields undefined and a shape-only assertion accepts that.

It also pins three things the roll-up quietly depends on:

• the dailyProgress[length-1]-is-latest invariant behind totalHatches (reading the wrong end gives 1 instead of 7)
• per-nest grouping — a second nest must get its own rows, not the first nests
• an empty progress list yields [], not undefined

The guard is real, not nominal. I re-introduced the historical hateched typo and confirmed it fails 3 of the 6 cases, then reverted.

Docs

Chapter 11s entry now records the remedy as Done, and notes what is Still open: backend/ has no eslint and CI runs no tsc (#208), so the build-time half of the guard only fires when someone runs a local build.

Verification

check	result
tsc --noEmit (backend)	exit 0
vitest run (backend)	298 passed, 32 files
new contract test	6 passed
make check-citations	7 OK, 0 problems
all 6 pre-push guards	pass

One environment note worth having

scripts/check-duckdb-bind-claims.sh picks its interpreter with for cand in python3 python py. On Windows Git Bash python3 does exist — as the Microsoft Store alias stub, which prints "Python was not found" and exits non-zero. The loop takes it on the first iteration, so the script fails on a machine that has a perfectly good python. The comment above the loop assumes the opposite ("never python3").

The check passes once a real python3 is ahead on PATH (verified: "dev is LAN-reachable, prod is loopback-only"). Not fixed here since it is unrelated to this issue — happy to open a separate one, or add py -3 / an executable probe to the loop if you would like it in this PR.