feat(settings): populate canonical typed catalog

[Teakowa]

Summary

• populate stable locale-independent canonical setting identities for the reviewed typed settings projection
• collapse duplicate legacy/generated paths while preserving the existing parser/emitter precedence and source-preserving carrier
• validate effective settings catalog identities, scopes, presentation, and domain consistency during workshop-catalog-gen check
• document the consumer-facing typed catalog boundary and update Define the canonical typed settings schema and hero applicability model #109 ADR status

Verification

• cargo fmt --all -- --check
• cargo clippy --workspace --all-targets --locked -- -D warnings
• cargo test --workspace --all-targets --locked
• cargo run --locked -p workshop-rs --bin workshop-catalog-gen -- check
• git diff --check

Fixes #110

[Teakowa]

Post-merge QA audit — changes required

A full audit of the merged #110 implementation found correctness/acceptance gaps that mean #110 should not remain completed yet.

Blocker

1. The canonical concept normalization collapses distinct hero settings into the same public SettingId. canonical_concept() maps any key containing Damage to ability.damage and any key containing Healing to ability.healing, regardless of whether the definition is actually ability-targeted. The reviewed catalog contains distinct hero-level settings such as damageDealt% / damageReceived% and healingDealt% / healingReceived%. These therefore become the same canonical identity for the same Team/Hero target kind and the same Percent domain. That violates Define the canonical typed settings schema and hero applicability model #109/Build the canonical typed Workshop settings catalog #110's locale-independent setting concept identity contract (which explicitly uses concepts such as hero.damageDealt) and makes definitions_by_id() ambiguous in a way target shape cannot resolve.

validate_catalog() does not catch this because it only reports a repeated (SettingId, SettingTargetKind) when the value domains differ; same-domain semantic collisions silently pass.

Major

2. The duplicate/stale table validation cannot observe the duplicates it claims to validate. definitions() consumes table::entries(), while entries() already filters duplicate paths with first-wins semantics. The subsequent paths.insert() duplicate check in validate_catalog() is therefore unable to see a duplicate path or compare the hand-written and generated definitions for equivalence/conflict. This does not satisfy Build the canonical typed Workshop settings catalog #110's acceptance criterion that generation/checking detect stale/duplicate semantic tables rather than silently permitting parallel sources of truth.

3. The precedence documentation is reversed relative to the implementation. entries() says generated export entries take precedence, but it iterates ENTRIES.iter().chain(GENERATED_ENTRIES.iter()) and keeps the first path, so hand-written entries take precedence. The PR summary says existing parser/emitter precedence is preserved; the code does preserve hand-written-first behavior, but the durable code comment currently states the opposite.

CI being green does not cover these semantic failure modes. #110 is being reopened so the canonical identity/data contract can be repaired before another release.