fix: i18n attribute bindings should not inflate xref IDs for @for index variables

[Brooooooklyn]

In Angular's TS compiler, BindingOp.i18nMessage stores a direct object reference to the i18n.Message -- no XrefId is allocated during ingest. The xref for the i18n context is only allocated later in the create_i18n_contexts phase.

Oxc was allocating xrefs for i18n messages during ingest, inflating the xref counter and causing @for body views to get higher xref values than Angular. This made generated variable names like ɵ$index_N use the wrong N value (e.g., ɵ$index_70 instead of ɵ$index_66).

Change i18n_message fields from Option to Option across all ops, using the i18n message's instance_id as a dedup key instead of allocating xrefs. This matches Angular TS's approach of using object identity for dedup without consuming xref slots.

Fixes 8 mismatched files in the ClickUp comparison (158 → 150).

---

Note

Medium Risk
Touches i18n IR/plumbing across ingest and multiple phases, so mistakes could break message extraction/dedup and downstream codegen. Scoped to i18n message identity tracking (switching to instance_id) with added regression coverage, lowering likelihood of unnoticed behavior drift.

Overview
Stops i18n attribute bindings from consuming extra XrefIds during ingest by switching i18n message references across IR ops and phases from Option<XrefId> to Option<u32> (the parser-assigned instance_id).

ComponentCompilationJob now stores i18n_message_metadata keyed by instance_id and removes the message-key→xref cache, with ingest and i18n phases (create_i18n_contexts, extract_i18n_messages, ICU/i18n propagation/wrapping) updated to use instance_id for dedup and metadata lookup.

Adds an integration snapshot test ensuring an i18n attribute before an @for does not shift xref allocation, keeping generated ɵ$index_N variable naming aligned with Angular.

^{Written by Cursor Bugbot for commit fce544d. This will update automatically on new commits. Configure here.}