Task: Seed the today's market collection kinds

The database refuses a today's market collection kind ORE does not have, and each kind's key attributes live in one row rather than on every entry.

• A seeded lookup holds the twenty-four collection kinds, each with its ORE element name and its key attribute or attributes, derived from todaysmarket.xsd with the command recorded.
• todays_market_collection.collection and todays_market_configuration_binding.collection refer to it, and an unknown kind is refused on insert.
• todays_market_entry.key_attribute is gone, and the today's market corpus and database round trips still pass.

• The kinds are the children of the todaysmarket type in external/ore/xsd/todaysmarket.xsd, apart from Configuration: twenty-four. Each kind's entry element and key attributes come from the same file; two kinds, SwaptionVolatilities and CapFloorVolatilities, identify an entry by key and currency.
• todays_market_collection_kind is an analytics lookup seeded for the system tenant and readable by every tenant, as pricing_engine_type is. Both collection columns resolve against it under the system tenant.
• key_attribute only ever repeated the kind's attribute, and the export never read it, so it leaves the entry table and the mapper.
• The mapper keeps one branch per kind, because the binding gives each kind its own member. A test checks the mapper's twenty-four names against the schema, and the seed test checks the lookup against the same schema, so the two cannot drift apart.

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.

Moved from Seed the configuration lookups. Decided in the PR #2500 review. A today's market document has twenty-four collection kinds (YieldCurves, DiscountingCurves and the rest). Today todays_market_collection.collection and todays_market_configuration_binding.collection hold the kind as free text, and every todays_market_entry row repeats the kind's key attribute in key_attribute. A seeded kind lookup would hold the kind code, its ORE element name and its key attribute, or attributes for the two kinds keyed twice. Both collection columns would then refer to it, and the database would refuse an unknown kind. key_attribute could then leave the entry table.

One limit for this document: the binding gives each kind its own typed member, so the mapper keeps one branch per kind whatever the lookup holds. The acceptance line "no lookup value appears as a literal in mapper code" cannot be met for today's market. The mapper can check its branches against the lookup instead.

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.

• New analytics lookup todays_market_collection_kind, 24 rows seeded for the system tenant from todaysmarket.xsd, each with its entry element and key attribute or attributes; readable by every tenant.
• todays_market_collection.collection and todays_market_configuration_binding.collection resolve against it under the system tenant; an unknown kind is refused on insert.
• todays_market_entry.key_attribute is gone from the table, the model and the mapper.
• Tests: the seed pinned to the schema; the mapper's twenty-four collection names checked against the same schema; a refusal case for an unknown kind. The corpus walk and the database round trip still pass.
• Migration analytics_todays_market_collection_kinds_migration.sql for existing databases.
• Build clean; ctest 89/89 after a database recreate.