docs: correct the sizes the 4 KiB rebuild produced

The databases came out of the first 4 KiB build at 288.6 MB and 237.7
MB, against the 302 and 247 the registry carried. That figure is a build
guard and is also shown to the user before the SQL tab opens, so both
uses were wrong by the same 5%.

The gzip variant the host builds for the HEAD request is now 64 MB, and
the published size claims in the deployment and architecture notes
follow the same rebuild.

datasets.json

@@ -20,12 +20,12 @@
     {
       "id": "2016",
       "expectedRows": 877460,
-      "dbSizeMb": 302
+      "dbSizeMb": 288
     },
     {
       "id": "2017",
       "expectedRows": 861068,
-      "dbSizeMb": 247
+      "dbSizeMb": 237
     }
   ]
 }

docs/deployment-guide.md

@@ -83,8 +83,8 @@ artifact — one missing line away from publishing it.
   files committed to a repository; the databases are built in CI and uploaded
   as a Pages artifact, and the documented Pages limits are a 1 GB published
   site and 100 GB/month of bandwidth, with no per-file figure. The two
-  databases are 302 MB and 247 MB.
-- **Total artifact is about 552 MB**, inside the 1 GB site limit but with less
+  databases are 288 MB and 238 MB.
+- **Total artifact is about 526 MB**, inside the 1 GB site limit but with less
   headroom than before: a third dataset of this size would not fit. The fallback
   is `sql.js-httpvfs`'s chunked mode, which splits a database into parts.
 - **Pages does compress the databases, and that is survivable.** The extension

docs/system-architecture.md

@@ -189,7 +189,7 @@ total descending.
   whole; GitHub Pages serves everything with `Cache-Control: max-age=600`, and
   every rebuild relays SQLite's pages so the file changes even when the data
   does not, so that caching is cancelled by the host. Worth revisiting behind a
-  CDN with long TTLs, and it is the fallback if a single 300 MB file ever
+  CDN with long TTLs, and it is the fallback if a single 288 MB file ever
   becomes a problem.
 - **`sqlite-wasm-http`.** Maintained, and built on the official SQLite WASM
   rather than a 2022 fork, which is the better long-term footing. It does not
@@ -200,7 +200,7 @@ total descending.
   but it ships a fallback backend that does not — so isolation is not the
   blocker, the missing length option is.
 - **Substring name search.** `LIKE '%x%'` cannot use an index, so it read the
-  whole 127 MB table. `name_word` keeps search by any word of a name without
+  whole student table. `name_word` keeps search by any word of a name without
   it.
 
 ## Risks and limitations
@@ -220,7 +220,7 @@ total descending.
   fails loudly instead of returning nonsense.
 - **`sql.js-httpvfs` is unmaintained** (0.8.12, September 2022) and ships its
   own SQLite WASM. `sqlite-wasm-http`, on the official build, is the fallback.
-- **Hosted size.** 552 MB for both datasets against the 1 GB GitHub Pages
+- **Hosted size.** 526 MB for both datasets against the 1 GB GitHub Pages
   limit; a third dataset of this size would not fit.
 - **Excel format drift.** A new source file with an unseen header layout needs a
   new branch in `parser/internal/ingest/detect2016.go` or a new config.

web/src/lib/db-probe.js

@@ -3,8 +3,8 @@
  *
  * `sql.js-httpvfs` sizes a file with a HEAD request. That request carries no
  * Range header, so the browser advertises gzip, and GitHub Pages answers with
- * `Content-Encoding: gzip` and the length of the *compressed* body — 66 MB for
- * a 302 MB database. The library rightly refuses to believe it and gives up
+ * `Content-Encoding: gzip` and the length of the *compressed* body — 64 MB for
+ * a 288 MB database. The library rightly refuses to believe it and gives up
  * with "Length of the file not known. It must either be supplied in the config
  * or given by the HTTP server."
  *