Seed community performance and security knowledge

Ports 14 concern-sized articles (8 performance, 6 security) and 25
AL samples from BC Code Intelligence, restructured to BCQuality's v1
schema and layered under /community/knowledge/. Each article is
atomic, under 100 lines, and ships <slug>.good.al and (where the
pattern has a clear anti-example) <slug>.bad.al siblings.

Jesper's microsoft-layer leaves (al-performance-review and
al-security-review) source across every enabled layer via
*/knowledge/<domain>/**, so these additions are picked up by the
existing action skills without any new skill definitions.

Performance (8):
  - use-deleteall-for-filtered-bulk-deletion
  - call-setloadfields-before-filters
  - load-common-fields-before-branching-on-case
  - load-only-primary-key-fields-for-reference-work
  - omit-filter-only-fields-from-setloadfields
  - choose-maintainsiftindex-by-read-write-ratio
  - avoid-growing-globals-in-singleinstance-subscribers
  - order-case-branches-by-frequency

Security (6):
  - classify-every-field-with-dataclassification
  - protect-sensitive-data-in-temporary-tables
  - guard-bulk-operations-with-istemporary
  - compose-permission-sets-with-included-sets
  - do-not-grant-rights-beyond-a-users-entitlement
  - prefer-oauth2-over-api-keys-for-external-http-calls

Graveyard-bound items (not ported; to be captured in a later
/docs/triage-graveyard.md):
  - testfield-performance (soft guidance, low actionability)
  - table-event-batch-operation-impact (keep-event-subscribers-lightweight
    already carries the core insight)
  - Most of /roger-reviewer (AL formatting - frontier-model territory)
  - sift-technology-fundamentals (descriptive, not a citable concern)
  - bc-telemetry-buddy-* (tooling promotion, not guidance)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

community/knowledge/security/prefer-oauth2-over-api-keys-for-external-http-calls.md

@@ -0,0 +1,28 @@
+---
+bc-version: [26..28]
+domain: security
+keywords: [oauth2, api-key, authentication, httpclient, token-refresh]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Prefer OAuth2 over API keys for external HTTP calls
+
+> **Seed article.** Ported from BC Code Intelligence to seed the community corpus. Community contributors are invited to expand or refine.
+
+## Description
+
+External HTTP integrations from AL can authenticate using OAuth 2.0 (client-credentials for service-to-service, authorization-code for user-delegated), API keys, basic authentication, or credentials in URLs. The mechanisms differ substantially in the blast radius of a leaked secret and in how cleanly tokens can be rotated. OAuth-issued tokens expire on their own schedule and rotate cleanly; API keys and basic-auth passwords typically have to be rotated manually and usually live unencrypted in a configuration table. When the partner supports OAuth, the difference is a material security improvement, not a stylistic preference.
+
+## Best Practice
+
+When the partner supports OAuth, use the platform `OAuth2` codeunit (`AcquireTokenWithClientCredentials` for service-to-service, `AcquireAuthorizationCodeTokenFromCache` for user-delegated flows) rather than hand-rolled token acquisition. Carry tokens and client secrets as `SecretText`, persist them only in IsolatedStorage, and refresh tokens proactively — on a buffer before the documented expiry — so routine calls never block on a token refresh.
+
+See sample: `prefer-oauth2-over-api-keys-for-external-http-calls.good.al`.
+
+## Anti Pattern
+
+Accepting an API-key or basic-auth integration because it is the first option documented, even when the partner supports OAuth. The shared secret usually ends up in a setup-table `Text` field, rotation becomes a manual operation that rarely happens, and a single disclosure exposes every tenant using the extension.
+
+See sample: `prefer-oauth2-over-api-keys-for-external-http-calls.bad.al`.