Story: Add a read-only entity profile

A named variability profile produces a read-only entity: the generated protocol carries list, get and get_many, and no write verb and no version read. Making ores.database a composite that can host such an entity — so the database metadata the UI needs can travel on the wire without the foundation library linking the layers above it — split to Make ores.database a composite and host the generated entity at the sprint 26 close on 2026-10-05.

The profile stands alone. Read-only entities are needed beyond this component, and the mechanism a profile carries is already implemented as a per-entity flag; this story made it bindable.

On 2026-10-05, at the sprint 26 close, this story was reworded to the profile it delivered and closed DONE. The composite is Make ores.database a composite and host the generated entity, and the task Make ores.database a composite and host the generated entity moved there.

• A model binds one named profile and the emitted protocol carries list, get and get_many only: no put_, no delete_, no *_versions_*.
• A codegen regression test covers the profile, so the read-only promise cannot regress in silence.

• The profile comes first. The composite depends on knowing what it hosts, and the profile is needed whether or not the composite happens.
• The composite task starts with a prototype of the api=/=core emission under one modelling directory, not with moving the library. If the generator duplicates output across parts, the shape of the composite changes, and the move would have been wasted.
• The clean-up story closed without the composite and without this component in COMPONENTS_UNDER_TEST. This story is not a continuation of that acceptance criterion; it adds capability the clean-up never had.

• The table ores_database_info_tbl was moved to hand-written SQL in the clean-up, so this story re-models an existing table rather than inventing one. It reads as operational metadata, and where the read surface lives is a product question this story does not settle: ores.database is the table's owner, while ores.telemetry already reports system state over NATS.
• Open question carried from the clean-up: ores.iam.account sets :read_only: true and generates no protocol. Its description credits a "one-owner gate" that could not be found in org_loader.py. Resolve it before the profile rests on the read_only flag.

• Reopening the ores.database clean-up story. It closed on the component as it stands, and its record says so.