fix(PC0021): suppress Microsoft-owned mismatches on supported TransferFields pairs

[Arthurvdv]

Problem

Microsoft ships and supports TransferFields calls between Base App tables whose same-ID fields differ. PurchaseHeader.TransferFields(PurchaseHeaderArchive) in ArchiveManagement.Codeunit.al:229 raises PC0021 on field 151 (Quote No. / Purchase Quote No.), and Tracking Specification ↔ Reservation Entry raises it on fields 31 and 900. The developer cannot rename Base App fields, and a #pragma on the call would also hide collisions on their own tableextension fields.

Root cause

• The call-site summary diagnostic fired for any mismatch FindFieldMismatches found, Base App fields included. The curated relation list only switched off the field-level reports.
• The relation lookup was per table (the source appearing anywhere in the list, as source or target), not per directional (source, target) pair.

Change

• Directional pair lookup: HasTableRelation(source, target) matches a curated relation only in the call's direction (source = argument record, target = receiver). Field-level reporting now follows this pair lookup.
• Microsoft ownership (ISymbol.IsMicrosoftObject() in Common): the namespace root is Microsoft or System; for namespace-less objects, the module publisher is Microsoft.
• Suppression: on a curated pair of two Microsoft tables, a mismatch is dropped only when both fields are Microsoft-owned. Once one side was added by the developer or a third party, the collision is outside Microsoft's support and is still reported.
• Own-module extension fields are always checked. A dependency tableextension field counts as Microsoft-owned only when that extension is Microsoft's.

Not changed

• The relation path (AnalyzeTableExtension).
• Duplicate field-level reports that already occur when both directions of a pair are curated and both sides carry extension fields. The review noted this; it is out of scope here.

Tests

Fixtures in both the PC0020 and PC0021 folders:

• Curated pair, Microsoft namespace (Tracking Specification → Reservation Entry): no diagnostic.
• Curated pair, Microsoft publisher, no namespace (Purchase Header Archive → Purchase Header): no diagnostic. The module publisher is set through the harness ProjectInfoCustomizer.
• Same curated pair under Default Publisher: still reported at the call.
• Curated Microsoft pair plus own-module tableextension fields that collide: still reported at the call.
• Non-curated pair of Microsoft tables: reported at the call and on both fields.
• Pair curated only in the reverse direction (Posted Bank Deposit Header → Bank Deposit Header): reported at the call and on both fields.

A single fixture cannot cover the Microsoft dependency-tableextension branch, because it needs a second module. The rule doc records this.

Follow-up

A separate alcops.dev docs PR will add a note on supported Base App pairs to the PC0020 and PC0021 pages.

Fixes #418

🤖 Generated with Claude Code