Task: Generate the blotter's common-date view

The blotter reads one set of date columns across the rates family, from a view generated from the models rather than hand-written.

• A common-date view exists, generated from the family's models, mapping each product's dates to the common names.
• A query over the view reads one date column across the rates family, including a FRA whose date is stated as an end date and a swaption whose dates describe its underlying swap.
• A later family adds its mapping by declaring it on its models, with no hand-written edit to the view.
• A generated test proves the mapping names the columns the models declare.

1. The mapping is a property of the models. Declare, on each product model, which of its columns states which common date; do not write the mapping in the view by hand.
2. Generate the view from those declarations, as the rest of the schema is generated, so a later family adds its mapping by declaring it.
3. The common names. Trade date, start, expiry and maturity. The rates family is the first to map: a FRA states its maturity as an end date, and a swaption states its underlying swap's dates, so both are cases the mapping must get right rather than the easy rows.
4. The test. A generated test asserts the view's columns are the ones the models declare, and a query reads one date column across the whole family.

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

• Unblocked by unit 3: the header is the one row per rates trade the view reads its common dates from, which is why the view could not exist before it.
• It depends on no later unit and can run at any point after unit 3.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

The rates family now has a generated view, ores_trading_rate_instruments_common_dates_vw. It gives the deal grid four date columns, trade_date, start_date, expiry_date and maturity_date, whatever name a product states a date under.

• The vocabulary is in the catalogue. A new * Common dates table in ores.trading.trade_type_catalogue lists the four names. trade_date has an owner outside every family, so the table names the entity and column that hold it: trade_booking.trade_date.
• The mapping is on the models. A column declares :common_date: <name>. The rates header declares start_date and maturity_date. The swaption fact declares expiry_date. A FRA states its end date as the header's maturity_date, as unit 3 decided. A swaption's header dates are the underlying swap's, and they read as null when the document does not carry them.
• The view is generated. The loader reads the declarations from each routed header and the tables its * Delete cascade names. Two new archetypes in the ores.sql.trade_type facet write the create and the drop script. A later family declares :common_date: on its columns and gets its own view, with no edit to a view.
• The loader refuses a bad mapping. It fails on a name outside the vocabulary, a date stated twice in one family, a name the catalogue holds elsewhere, and a column in a table that is not keyed by the trade alone.
• Test. test_common_dates.py holds the view's columns to the columns the models declare, and holds the committed SQL to the loader's output.

Not done: the view has no C++ reader yet, and no ER diagram shows it.