Analyse whether timeseries/observation entities need their own codegen metatype

First analyse, don't decide up front: is a timeseries/observation entity (append-mostly, high-volume, TimescaleDB hypertable, keyed by series + observation time + optional point rather than a single temporal-versioned row) different enough from a standard domain_entity to warrant its own MASD metatype (a real #+type: ores.codegen.timeseries_entity-style dispatch value, its own archetype set), or whether it's adequately expressed today as a domain_entity with a particular variability-knob combination (as market_observation currently is, with :ores.cpp.qt.enabled: false disabling the standard Qt layer). Once that's settled, do the codegen work to support an appropriate UI for observations – a list/chart view, not the standard generated CRUD detail dialog – since we want observation data browsable and eventually plottable, not just queryable via the API.

Raised while reviewing the codegen entity meta-model doc (Codegen org-entity meta-model) during task EE237306 (scaffold entity .org templates per metatype). ores.marketdata.market_observation was picked as a candidate exemplar and immediately raised the question of whether it belongs in the same bucket as currency=/=party at all. Answering that properly needs an actual look at the codegen archetype system and TimescaleDB hypertable specifics, not a snap call made in passing while documenting an unrelated task – hence this as its own capture.

• Applied MASD § Metatypes, facets, archetypes, and transforms — the established metatype list (domain_entity/junction/enumeration/field_group/component) this analysis would extend if warranted.
• projects/ores.marketdata/modeling/ores.marketdata.market_observation.org — the entity that prompted this.
• Codegen org-entity meta-model — documents the :ores.cpp.qt.enabled: flag currently used to opt market_observation out of Qt generation.

• Task: Scaffold model .org files per entity type (regular/enum/junction)