knowledge(performance): align SetLoadFields placement with AL Guidelines

[Jesper Schulz-Wedde (JesperSchulz)]

Resolves the contradiction reported in #120.

The question

The AL Guidelines mark SetLoadFields placed before SetRange/SetFilter as bad code; BCQuality's samples used exactly that order.

The answer

The order is a readability convention, not a behavioural one. Per Record.SetLoadFields on Learn:

Depending on the runtime version, the runtime may require extra fields to be selected for loading. […] For example, fields that are filtered upon are always loaded.

So both orders materialize an identical projection. SetRange/SetFilter never resets the load-field selection — only a fieldless SetLoadFields() (which resets to all readable normal fields) or a later SetLoadFields(...) overwriting an earlier one changes what is loaded.

The upstream rule is about keeping SetLoadFields adjacent to the read it governs — the same rationale as the AL Guidelines' case-statement example, which BCQuality already mirrors in load-common-fields-before-branching-on-case.md. That page is tagged Readability, not Performance.

Changes

BCQuality now follows the AL Guidelines order, and states explicitly that the order is not technically relevant so the two repos cannot be read as contradicting each other.

• Reordered filters ahead of SetLoadFields in the six affected AL samples:
  • use-setloadfields-for-partial-records.{good,bad}.al
  • load-only-primary-key-fields-for-reference-work.good.al
  • avoid-cloning-records-before-modify-delete-in-loops.{good,bad}.al
  • use-setautocalcfields-for-per-row-flowfields.{good,bad}.al
• use-setloadfields-for-partial-records.md:
  • Best Practice — place the call immediately before the read, after any SetRange/SetFilter.
  • Description — the order does not change the projection; only a fieldless or overwriting SetLoadFields does.
  • Anti Pattern — statement order is explicitly not part of the anti pattern, so a review agent reports the reverse order as a readability observation at most, never as a performance defect.

The Anti Pattern placement is deliberate: per skills/read.md, only ## Best Practice and ## Anti Pattern are normative, so a false-positive suppression has to live there to be honoured by consumers.

Validation

All three CI validators pass locally:

• validate_frontmatter.py — 0 errors, 0 warnings
• Test-KnowledgeIndex.ps1 — 255 articles, deterministic, full coverage
• Test-ReviewFixtures.ps1 — 32 cases across 16 leaf domains

Closes #120