Fix silent contact-matrix/transmission-mode misattribution

[gavdoubleu]

Title: Fix silent contact-matrix/transmission-mode misattribution (default-matrix path + per-mode path)

Original bug

contact_matrices.yaml's default_contacts_matrix is meant to be the fallback
contact matrix used whenever a (venue type, transmission mode) pair has no
dedicated entry. Every production config writes this key in modes: form
(per-mode matrices), but the loader only ever parsed it as a flat single
matrix. Result: default_contacts_matrix silently resolved to an empty
matrix on every real config, and every lookup that needed it fell through to
a hardcoded scalar, ContactMatrixConfig::default_contacts = 2.0, with no
error, no warning, and no relation to whatever beta/contact rate the user had
actually configured. Simulated infection numbers for any venue/mode without
an explicit matrix were silently wrong, and there was no way to tell from
config or logs that this was happening.

There was a second, more subtle layer to this: even after fixing the parser,
ContactMatrixConfig::resolve() only built the per-mode default lookup table
(default_mode_matrices_by_id) when mode_names was non-empty. A config
that supplies default_contacts_matrix.modes but has no venue-level
contact_matrices: ... modes: block leaves mode_names empty, so the table
was never built and the per-mode default stayed unreachable — surfacing
later as a runtime std::runtime_error instead of the load-time failure ADR
0006 was meant to guarantee.

A third, independent bug affected the primary (non-default) per-mode lookup:
disease.yaml's transmission_params.modes and contact_matrices.yaml's
per-venue modes: blocks are two independently-ordered lists. getMatrix/
getVirtualMatrix indexed contact matrices by the raw disease-mode index
into contact_matrices.yaml's list, silently misattributing a matrix
whenever the two files declared modes in different orders (e.g. a fomite
matrix applied to droplet transmission).

Fix, in order

1. 2aa6dd3 / 9bed681 — Parse default_contacts_matrix in both flat and
   modes: form (mirroring the existing per-venue parser), bin-resolve it
   like every other matrix, and delete the default_contacts scalar
   fallback entirely. The key is now mandatory: a venue/mode with no matrix
   anywhere is a load-time error, not a silent stand-in value (ADR 0006).
2. 5d64c38 — lookupContactsForBinPair now throws instead of returning
   0.0 when a matrix is still missing at that point — by then the default
   chain guarantees non-null, so hitting this branch means a real bug
   (mismatched bins), not a config gap to paper over.
3. 15e4da5 — getVirtualMatrix (virtual encounters) never consulted
   default_contacts_matrix at all, unlike the venue path — an encounter
   type with no dedicated matrix crashed instead of falling back. Extracted
   the shared default-fallback tail (applyDefaultChain) so venues and
   virtual encounters go through the same fallback logic.
4. d188e3c — Fixed the mode_names-empty gap described above: added
   ContactMatrixConfig::finalizeDefaultModeMatrices(world, disease_mode_names), called from Simulator::Simulator right after
   disease_ loads (the first point both the disease's canonical mode list
   and ContactMatrixConfig co-exist), which rebuilds the per-mode default
   table keyed to the disease's actual modes and throws if any disease mode
   has neither a per-mode default nor a flat fallback (ADR 0007).
5. e99e511 — Consolidated the bin-resolution logic that step 4
   duplicated from resolve().
6. e5bbcec / efe472f — Removed the now-dead default_contacts key from
   tracked config YAMLs; untracked config_plague_fitting /
   config_plague_fitting_short (large generated fixtures that shouldn't be
   version-controlled).
7. bc18375 — Fixed the primary (non-default) per-mode lookup positional
   mismatch described above. Added
   ContactMatrixConfig::finalizeDiseaseModeAlignment, building a
   name-matched disease-mode-index → contact-matrix-mode-index permutation
   vector (mode_index_translation_) once at Simulator construction,
   right after finalizeDefaultModeMatrices. getMatrix/getVirtualMatrix
   translate through it via a new translateModeIndex helper before
   indexing. A disease mode absent from contact_matrices.yaml falls
   through to the existing default chain; a contact_matrices.yaml mode
   absent from the disease warns and is ignored (configs may be shared
   across diseases with differing mode sets).
8. 8bddce4 — Closed two follow-up correctness gaps in the step-7
   mechanism, found by review:
   • finalizeDiseaseModeAlignment's name-matching used break-on-first-match
     with no uniqueness check, so two transmission_params.modes entries
     sharing a name (or both omitting one, defaulting to "default")
     collided — the second mode's matrix silently aliased onto the first's,
     the same failure class as step 7 fixes, just triggered by an in-file
     naming collision rather than cross-file ordering. Now throws on a
     duplicate disease mode name instead of aliasing.
   • translateModeIndex used an empty mode_index_translation_ to mean
     "not yet finalized, fall back to raw positional indexing" — but
     finalizing with a genuinely empty disease-mode list produces the same
     empty vector, making "finalized, zero modes" indistinguishable from
     "never finalized" and reverting to unsafe positional lookups. Added an
     explicit disease_mode_alignment_finalized_ flag as the sentinel
     instead of inferring it from vector emptiness.

See docs/adr/0006-default-contact-matrix-fails-loud-no-scalar-fallback.md
and docs/adr/0007-default-mode-matrix-finalised-in-simulator-constructor.md
for the design rationale behind steps 1-6. Steps 7-8 are bug fixes to that
existing mechanism, not new architectural decisions, so no new ADR.

Test plan

• ctest — fixtures rewritten off ContactMatrixConfig::default_contacts;
  new fixtures cover missing default, missing mode in default, empty
  mode-names-with-per-mode-default, reversed disease/contact-matrix mode
  order, orphaned contact-matrix mode names, duplicate disease mode names,
  and zero-disease-mode finalization
• Run a config with default_contacts_matrix.modes and no venue-level
  contact_matrices: modes: block — confirm it no longer throws at runtime
  and no longer silently uses a stale scalar
• Run a config where disease.yaml and contact_matrices.yaml declare
  the same mode names in different orders — confirm matrices attach to the
  correct mode