Record and gate proofs, so "proven" means Lean verified it

The index had no proof field and every entry was an axiom, so the
database asserted its premises rather than proving them. Adds the proof
half, with the verification gate that makes the status trustworthy.

- Database records now carry `proof` and `proof_checked`, and the search
  index exposes the proof, with status one of proved / proof_pending /
  asserted. build_database.py emits a real `theorem` only when a proof
  has been verified (by check_proofs.py, or by a lean-bench run via
  --results); a recorded but unverified proof stays an `axiom` and is
  reported as proof_pending, so the library never claims more than Lean
  has confirmed. A test pins that gating in both directions.

- textbook/check_proofs.py verifies proofs by compiling
  `theorem ... := by <proof>`. Stricter than check_statements.py in three
  ways: it rejects sorry/admit/native_decide outright, and it reads
  `#print axioms` to reject any proof depending on more than Lean's own
  three axioms (propext, Classical.choice, Quot.sound) -- which in
  particular catches a proof leaning on one of this database's own
  book-asserted axioms, since that is not an independent proof. With
  --update it writes proof_checked back, promoting entries on the next
  build.

- Ten candidate proofs recorded, all currently proof_checked=false
  pending a Lean run: goodman-1-6-1 (the eight algebraic identities are
  `ring`, plus a short argument for the nonzero conjunct), the four parts
  of Proposition 1.6.2 (Int.mul_eq_one_iff_eq_one_or_neg_one,
  associated_of_dvd_dvd with Int.associated_iff, dvd_trans, dvd_add with
  mul_left), 1-6-4 (Nat.exists_prime_and_dvd), 1-6-15
  (Int.gcd_eq_one_iff_coprime, where IsCoprime unfolds to exactly the
  target existential), 1-6-17 (IsCoprime.mul_dvd via
  Nat.isCoprime_iff_coprime), 1-6-19 (Int.Prime.dvd_mul') and 1-6-20
  (Prime.dvd_prod_iff). These are citations of existing Mathlib results,
  which is the realistic way to populate a textbook premise library --
  the remaining 11 (1-6-6, -7, -9, -10, -11, -13, -18, -21, -23, -24,
  -26) are the ones needing actual work and carry no proof yet.

Written without Lean available here, so expect a real failure rate on
first compile -- run check_proofs.py --update and send back the FAILED
ids with diagnostics, same loop as the statement fixes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017vbLFFJiHSZqGZHEkjvG5x

textbook/README.md

@@ -169,7 +169,28 @@ task, matching how `check_statements.py` elaborates one task at a time), so
 `lib/Definitions.lean` is the single canonical copy and the inlined ones must stay
 in sync with it by construction (generated from the same manifest).
 
-### 7. Generate the citable premise database
+### 7. Verify recorded proofs
+
+A database entry may carry a `proof` (hand-written, or authored by an agent outside
+a bench run), but it stays an `axiom` until Lean compiles it -- an unverified proof
+never upgrades an entry, so the library cannot claim more than Lean confirmed.
+
+```sh
+python3 textbook/check_proofs.py database/goodman-1.6.jsonl \
+  --lean-project /path/to/your/mathlib-project \
+  --lean-command '["lake","env","lean"]' \
+  --report textbook/goodman-1.6.proof-report.jsonl \
+  --update
+```
+
+Stricter than check_statements.py: it compiles `theorem ... := by <proof>`, rejects
+`sorry`/`admit`/`native_decide`, and reads `#print axioms` to reject a proof that
+depends on anything beyond Lean's own three axioms -- notably one that leans on a
+book-asserted `axiom` from this very database, which would not be an independent
+proof. `--update` writes `proof_checked` back, which is what promotes an entry on
+the next build.
+
+### 8. Generate the citable premise database
 
 ```sh
 python3 textbook/build_database.py database/goodman-1.6.jsonl \