Task: Add tenant_read_scope: shared to badge_mapping_junction, regenerate all three badge repositories

Fix the cross-tenant badge lookup regression (see parent story * Goal for the full root-cause writeup):

1. Add :tenant_read_scope: shared to ores.dq.badge_mapping_junction.org's properties – it doesn't have the flag set at all.
2. Regenerate all three entities via codegen (compass codegen entity generate <entity> --address <repository facet's address> – check the archetype for the correct address, since badge_definition=/=badge_severity already have the flag and their generated .cpp is just stale).
3. Verify the regenerated diff carefully before accepting it: diff the regenerated repository files line-by-line against current, and if anything unrelated to the tenant-filter change shows up, treat that as separate pre-existing drift to flag, not something to silently accept – this exact trap hit a different generated file (iam_service_db_grants_create.sql) earlier this session, silently reverting unrelated hand-added grants never round-tripped back into the source .org.
4. Rebuild, recreate the DB, log in as a non-system tenant, confirm badges render with real colours (not the orange fallback) and ores.dq.service.0.log shows Total: 63=/=Total: 114 (or current row counts) instead of Total: 0.

Superseded mid-task by live QA findings – see * Result for what actually shipped. Original acceptance criteria (below) are struck through as no longer the goal:

• [ ] =ores.dq.badge_mapping_junction.org= declares =:tenant_read_scope: shared= – reverted; junction's shared-read case no longer exists (see story * Decisions).
• [ ] Regenerated =badge_definition_repository.cpp=, =badge_severity_repository.cpp= no longer hard-code =tenant_id = ctx.tenant_id()= on read methods – reverted back to tenant-filtered reads after live QA found duplicate-row regressions.
• [X] Regenerated-diff review found no unrelated drift for either entity's ores.cpp.repository=/=ores.sql.schema facets; the natural-key migration needed for badge_definition (moving name into Columns with :natural_key: true, discovered when the first migration attempt silently dropped the column from the generated entity/mapper) is documented in * Plan rather than silently folded in. – Still true; this part of the work stands.
• [X] Verified live as a non-system tenant via the QA Validation Runner (scenario_verify-badge-tenant-scoping.org): confirmed the original symptom no longer reproduces (bundle-publish gives each tenant its own copy), and confirmed the RLS-fallback fix's duplicate-row regression before deciding to revert it.

Turned out to be three layers deeper than the story anticipated:

1. Primary-key model shape. badge_definition.org=/=badge_severity.org declared their primary key via the legacy * Primary key heading, which the current org_loader.py no longer reads at all – validate_model() only derives primary_key from a :primary_key: true flag inside * Columns. Confirmed this is repo-wide pre-existing breakage, not badge-specific: regenerating catalog (unrelated, also un-migrated) hits the identical validation error. ~61 of 120 ores.codegen.entity models are still on this legacy shape and can't be regenerated via codegen today. Migrated just badge_definition=/=badge_severity to the new shape (mirroring ores.dq.subject_area.org, the one fully- migrated exemplar in this component), rather than attempt the wider repo-wide migration – out of scope here.
2. Natural-key model shape (same category, easy to miss). The first migration attempt moved only the primary key and left name under the old * Natural keys heading. That heading is also dead in the current loader – natural keys need :natural_key: true inside * Columns too. Regenerating with only the primary key migrated silently dropped name from the generated entity/mapper entirely (a real data-loss bug, caught by diffing before applying, never applied). Migrated both key roles together.
3. Generator-suffix double-application. Copied the checked-in generator's + "-" + std::to_string(idx) suffix verbatim into the migrated model's :primary_key: generator block; the codegen generator template already appends that suffix automatically for text primary keys (and, separately, for text natural keys) – copying it produced a doubled suffix in the regenerated generator.cpp. Caught via the full (non-address-restricted) diff; fixed by providing only the base expression.

badge_definition=/=badge_severity regenerated at ores.cpp.repository (clean diff: tenant-filter removal + harmless template-formatting cosmetics only) and ores.sql.schema (zero diff). Did not run the default full-address regeneration for these two entities in this task: it also touches Qt/service/generator layers where separate, genuinely unrelated pre-existing drift surfaced (e.g. a hand-added guard in BadgeDefinitionDetailDialog.cpp against deleting the reserved __unmapped__ fallback badge would be silently dropped) – flagged as a distinct pre-existing issue, not touched here, since neither is related to the tenant-filter fix.

badge_mapping (junction) is the third layer – see * Notes and the split-off follow-up task (later abandoned, see below).

Flagged, not fixed here (out of scope for this task):

• A full (non---address-restricted) regeneration of badge_definition shows unrelated pre-existing drift in BadgeDefinitionDetailDialog.cpp (a hand-added guard preventing deletion of the reserved __unmapped__ fallback badge would be silently reverted) and ClientBadgeDefinitionModel.cpp=/ =BadgeDefinitionDetailDialog.ui (Qt-layer template evolution since these were last regenerated – tooltip role handling, colour-button placeholder text). None of this is related to the tenant-filter fix; worth a separate capture if the Qt layer for these entities is ever intentionally regenerated.
• ~59 other ores.codegen.entity models still on the legacy * Primary key=/=* Natural keys heading shape are equally unable to regenerate via codegen today. Worth a backlog capture to track the wider migration, since this task only touched the two badge entities.

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

Net change from this task: badge_definition.org/badge_severity.org migrated to the current Columns + :primary_key:/:natural_key: model shape (a real, harmless prerequisite fix, unblocking any future regeneration of these two entities); everything else reverted.

The originally-reported cross-tenant badge bug turned out to already be fixed on current main by an independent, unrelated upstream change (tenant provisioning now bundle-publishes badge data per tenant). Applying the tenant_read_scope: shared fix on top of that caused a new regression (duplicate rows in the Badge Definitions/Severities admin lists), caught via live QA and reverted before merge. No functional code change ships from this task; the model-shape migration is the only lasting artefact, plus two backlog-worthy findings recorded in the story's * Out of scope (wider legacy-model-shape migration; Qt severity-combo duplicate/ non-badge rendering).