Catalog — group tables, screens, reports and programs into a named application

[DDecoene]

See docs/roadmap-v1.4-v1.5.md.

Why

dBASE IV's catalog manager, named specifically by a user who lived through it:

"so many memories of dBase, I started with IV so it had the catalog manager as well as the dot commands."
— garyk1968, r/retrocomputing

Today a WebBase-III "app" is a loose pile of objects sitting in a database: some tables, a few .prg files, a report definition, and (after #73) some screens. Nothing ties them together, names them, or says this set of things is one application.

Two reasons that matters now:

1. It is the unit of publishing. v1.5.0 exports an app to a URL — it needs to know what "the app" is.
2. It is what makes the demos legible. crm.prg, INVENTORY.prg and overtime.prg each create tables, a report and a program, and a newcomer has no way to see those as one thing.

Scope

• CREATE CATALOG <name> / SET CATALOG TO <name> / LIST CATALOGS / DELETE CATALOG <name>.
• A catalog references: tables, screens (CREATE SCREEN / MODIFY SCREEN — visual form designer emitting editable W3Script #73), reports, programs — by name, scoped to a database.
• ADD TO CATALOG / REMOVE FROM CATALOG, or membership managed via a wizard (decide during design).
• Storage in data/system.sqlite3 (CatalogStore.ts, same discipline as ProgramStore/ReportStore/IndexStore).
• Assistant parity: a Catalog category — pick a catalog, see its objects, open one.
• Convert the three demos to ship as catalogs, so crm is one named app rather than a pile.
• Playwright e2e for the Assistant path.

Design question to settle first

Is a catalog a view over existing objects (a named list, objects still stand alone), or does it own them (deleting the catalog deletes its objects)? dBASE IV's was the former — a catalog was a convenience index, and objects lived independently. Recommend matching that: it keeps the feature additive and makes v1.5.0's export a pure read.