Task: Build the pure batch tenor resolution engine

The server cannot answer what date a tenor resolves to, and the screen that authors a tenor rule can never show its answer. Build the answer as a pure, batch engine in ores.analytics.quant: flat vectors of plain data in, flat vectors of results out, no database, no NATS, no refdata coupling. The engine reproduces QuantLib's date, period and calendar semantics - the engine of record for this project - rather than inventing a second set of rules, and it is pinned by QuantLib's own test cases. The NATS operation and the screen that calls it come later, on top of this.

• ores.analytics.quant gains a pure date-arithmetic service reproducing QuantLib's date, period and calendar-advance semantics and all seven business-day conventions, depending on nothing but the standard library and this component's own calendar rule data.
• ores.analytics.quant gains a batch tenor resolution engine: a flat span of requests in, a flat vector of results out, aligned by index, one status per row, and no exception crossing the batch boundary.
• Tests ported from QuantLib's own suites - its thirty-five business-day-convention cases, its date and period cases, and the IMM and ASX invariants - and the cases refdata's resolver already covers, all passing.
• ECB is excluded, and this bullet replaces the one that named it. QuantLib 1.31.1 has no formula for ECB dates, only a 144-entry table that stops at 2017-12-20 and past which its own nextDate throws; nothing in this codebase consumes one. Porting it would ship a dead table and a function that fails for every current date. The decision is the maintainer's to overrule; it is recorded here rather than left as a silent omission.
• Every non-date input is a strongly typed enum and the refdata code strings are parsed once, at the boundary, so no engine code compares strings.

Two layers, because the two questions are different ones.

calendar_arithmetic under the service layer answers "what date does this arithmetic give", one function per QuantLib entry point, named after it. tenor_resolution_engine answers "what date does this tenor resolve to", reading a flat request per row and returning a flat result per row.

The boundary decides the shapes:

• Holidays arrive as data (business_day_calendar_set), never as a calendar object, so the engine holds no global state and no calendar of its own.
• Calendar indices and schedule rows are positional, so the engine owns no code<->index mapping; the caller does.
• Every non-date input is an enum, and the persisted code strings are parsed once, in date_convention, tenor_resolution and calendar_rule.
• A malformed row is a status, not a throw. An operation needs a refusal payload; a screen needs one bad row not to empty the list.

SouthAfrica is transcribed because QuantLib's own business-day-convention suite drives all thirty-five of its cases through it, and replaying them is the strongest evidence the conventions are right. That needed a fourth observance_shift, sunday_to_monday: QuantLib's SouthAfrican holidays move a Sunday to the Monday and leave a Saturday alone, where roll_forward_to_monday moves both.

ROLL_QUARTER is the CDS roll date – the 20th of March, June, September and December, stated unadjusted – and the roll convention moves it, not the schedule. The two conventions that trade under the name "IMM date" are different dates; doc/knowledge/domain/imm_dates.org states both.

Both the header work and the to_code pairs were widened beyond the acceptance bullets' letter where a persisted vocabulary demanded it, and narrowed where nothing consumed it: see the * Review table.

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.

The one gate failure, entity-writes, is not this branch's: it names ores_marketdata_publish_curve_series_fn, which is already on main and already unbaselined, and which feature/implement-imm-roll-tenor-resolution is fixing. This branch touches neither file.

The engine is the arithmetic and nothing above it. The NATS operation, the refusal payload and the screens that call it are CFE1A720, and they are small now.

Follow-ups this task deliberately left:

• refdata's resolve_end_date still exists, still compares persisted code strings, and still applies no business-day convention at all. It disagrees with this engine on two counts: a day-counted period (calendar days there, business days here, which is QuantLib's) and whether to roll at all. Moving refdata and the web journey onto the engine is its own task.
• tenor_anchor::imm_roll and near_leg are refused rather than guessed at. The persisted description of IMM_ROLL says "nearest" where QuantLib defines only "next", and no convention resolves from either, so the meaning is a decision nobody has made yet. The IMM primitives are there for it.
• The component's older test files (business_day_calendar_set_tests.cpp, calendar_rule_engine_tests.cpp, day_count_calculator_tests.cpp) still do not carry the layer prefix unit_test_conventions.org asks for. This task renamed only the three files it added; renaming the others is a tidy of its own.

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 engine is built, tested and reviewed on both axes. ARITHMETIC: all seven business-day conventions, QuantLib's period clamping, its end-of-month predicate, and the IMM and ASX date families, each pinned against QuantLib's own expected values or its own invariants. RESOLUTION: a flat batch that answers every row, reports a malformed one instead of throwing, and refuses what it cannot know rather than inventing a date.

Thirteen review findings: six accepted and fixed or recorded, one partly accepted, two declined with a reason, and four rejected with the QuantLib source quoted against them. One acceptance bullet was amended after the review, and the amendment is stated above rather than folded in silently.

Merged to main as 6f6f11efb9, rebased onto origin/main (5d0fa921e8) first. On the merged tree the local gate is 15 of 15 – the entity-writes failure this branch had documented as pre-existing is gone, because main picked up the baseline entry for ores_marketdata_publish_curve_series_fn from the IMM roll work. Both suites re-run on that tree: ores.analytics.quant.tests 432 cases and ores.refdata.core.tests passing.

The parent story's * Decisions still needs the two decisions this task settled – positional calendar indices with the caller owning the code<->index mapping, and a refusal as a row's status rather than a throw – distilled into it at story close.