Explore: expand Schema to carry relation-level properties beyond columns/indexes

[JJJ]

Background

Fell out of the #235 (View) / #237 (Table decomposition) design. Today the declaration split is:

• Schema = structure: columns, indexes, relationships.
• Table = physical attributes + lifecycle: engine, charset/collation, row_format, auto_increment, comment, name/prefix, install/version.

The View work surfaced the first relation-level policy that naturally wants to live with the declaration a Query consumes: read-only. A Query already holds its table_schema, so read-only-ness should be DERIVED from the schema (Query::can_write() reads Schema::is_read_only(), Crud gates writes), not declared per-call - so a caller never has to know it is querying a view. That is landing as part of the View work: a read_only Schema property (default false; a view's schema sets it true).

The broader question

read_only is the first property to cross the columns/indexes boundary on Schema. Should Schema become the SINGLE relation-declaration surface - also carrying attributes that currently live on Table (engine, charset/collation, row_format, comment, ...)? That would make Schema the one thing a developer declares and both Table/View and Query consume, instead of splitting structure (Schema) from physical attributes (Table).

Appealing, but non-trivial:

• BC: Table's engine/charset_collation/etc. config keys are @since released; moving their home needs care (accept on both, or deprecate).
• Some attributes are genuinely Table-only (engine has no meaning for a view), so it is not a clean lift-and-shift - it is "which properties are relation-declaration vs installer-specific."
• Interaction with Decompose Table into shared storage/relation traits (foundation for View #235) #237 (the shared Storage traits) and the declare-vs-discover axis (CLAUDE.md).

Scope

Research/design only. The read_only property ships with #235 regardless; this issue tracks whether to generalize the pattern. Related: #235, #237, #232.

[JJJ]

Working answer, now captured in-code on the `Schema::$read_only` docblock (230c316):

The test for what belongs on Schema vs Table is what vs how, not shared. A property belongs on Schema when it is part of what the relation is — a fact more than one consumer (Query/Table/View) reads to reason about the relation. It belongs on Table when it is part of how the physical table is stored (installer-only).

• columns / indexes / relationships -> Schema (structure; everyone reasons about them)
• read_only -> Schema (a behavioral policy; Query reads it to gate writes)
• engine / charset_collation / row_format / auto_increment / comment -> Table (pure physical storage; only Table::create() touches them; a View has none, a Query does not care)
• temporary / foreign_keys (deferral) -> Table (install-time behavior)

So: no wholesale relocation of Table's physical attributes onto Schema just because Schema is the shared surface / there is no global state. That is convenience, not a reason.

And no generic $settings/$properties bag. columns/indexes are arrays because they are collections of like items; relation-level policies are individual scalars, not a collection. A grab-bag also runs against the discoverability principle. Add each relation-level property by name, earning its sanitizer + is_*()/get_*() accessor, exactly as read_only did — and only when a real cross-consumer need appears.

read_only is the first and (so far) only crossing, and it is marked provisional — the intent is to remove its need eventually, not to grow a pattern around it (cf. #239, closed as disproportionate). Recommend keeping this issue as the research anchor but treating "case-by-case, named, what-vs-how" as the settled answer.