docs(catalog-sync): surface the bundle extension and the page-writing nuance

`.hab` has been the stored bundle extension since the `FURNI_BUNDLE_EXT`
switch, so the repair path already writes `.hab` (the sources serve `.nitro`),
but nothing in the output said so. Print the resolved extension in the run
header and correct the header comment: generating the catalog SQL also creates
the `catalog_pages` sub-pages it references, so a "generate only" run is not
entirely read-only — only the `catalog_items` rows wait for `--apply-sql`.

scripts/catalog-sync.ts

@@ -29,12 +29,16 @@
 //   --fail-on-errors   exit 3 when error-severity issues remain
 //
 // Audit is read-only by default: nothing is written until one of the repair
-// flags is passed, and `--apply-sql` is the only flag that changes the catalog.
+// flags is passed. One nuance: generating the catalog SQL also creates the
+// `catalog_pages` category sub-pages it references (exactly like the app's own
+// import does) — only the `catalog_items` rows wait for `--apply-sql`. Use
+// `--organize-sql` to also emit those page INSERTs into the .sql file.
 
 import "./load-env";
 import { mkdir, writeFile } from "node:fs/promises";
 import { join } from "node:path";
 import { pathToFileURL } from "node:url";
+import { LOCAL_BUNDLE_EXT } from "@/lib/furni/classname";
 import type { AuditEvent, AuditSummary } from "@/lib/services/catalog-audit";
 
 /** Where generated catalog SQL is written (`storage/` is gitignored). */
@@ -260,7 +264,7 @@ export async function commandRun(flags: CatalogSyncFlags): Promise<number> {
 	let pendingSql: string | undefined;
 
 	log(
-		`Catalog sync — ${selected.length} source(s), ${describeActions(flags)}` +
+		`Catalog sync — ${selected.length} source(s), ${describeActions(flags)} — bundles stored as ${LOCAL_BUNDLE_EXT} (FURNI_BUNDLE_EXT)` +
 			(flags.applySql ? "  [SQL WILL BE APPLIED]" : ""),
 	);