Story: Entity classification and drift baseline: ores.iam

Bring ores.iam to the same proven state as the ores.refdata pilot: every codegen-eligible entity (discovered once, under projects/ores.iam/modeling – the iam and iam-cpp catalogue entries share the same modeling_dir and no longer have a live legacy-JSON split, so this is one survey, not two) bound to a profile or recorded as a genuine no-match, zero-diff regeneration verified, and any real gap the check surfaces fixed rather than skipped. Once trusted, iam and iam-cpp are added to the CI regeneration-drift check.

• Every ores.iam entity is bound to a matching Variability Profile, or recorded as a genuine no-match with a documented reason.
• Every rebound entity is regenerated and diffed against its pre-rebind checked-in output; zero diff is the pass condition, and any non-zero diff is fixed, not worked around.
• Full local build clean, validate_schemas.sh green, full ctest suite green after regeneration.
• check_component_drift.py –components is extended to include iam and iam-cpp, and the refdata-codegen-drift CI job is updated so future PRs touching ores.iam fail on any regeneration drift.
• The superseded ad hoc task 'Apply safe drift to iam-cpp' is marked ABANDONED, pointing here.
• The known starting-point wrinkle already recorded for iam-cpp (service_find_prefix on tenant_type and tenant_status) is resolved as part of reaching zero drift.
• The known, previously-flagged tenant_type has_tenant_id model/table drift (see capture 2F793500-FBD1-4E4F-8B6E-15D03337FBD2) is investigated and resolved, not left as stale drift.