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/do-not-grant-rights-beyond-a-users-entitlement.md

@@ -0,0 +1,26 @@
+---
+bc-version: [26..28]
+domain: security
+keywords: [entitlement, permissionset, license, clipping, sandbox-drift]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Do not grant rights beyond a user's entitlement
+
+> **Seed article.** Ported from BC Code Intelligence to seed the community corpus. Community contributors are invited to expand or refine.
+
+## Description
+
+Entitlements are license-level caps on what a user can access, derived automatically from the BC license tier. Permission sets are application-level grants administered on top of the entitlement. A permission set can only grant within the entitlement's boundaries; grants beyond those boundaries are silently clipped at runtime. This means a permission set authored and validated in a developer sandbox (with a broad license) can appear to work correctly there and fail silently in a customer tenant where users hold a narrower entitlement.
+
+## Best Practice
+
+When designing a permission set that ships with an extension, consult the entitlement model for the target user population before finalizing the grants. Every object and tabledata right the set expects to grant should be reachable within the intended entitlement tier; if it is not, the set needs to be scoped to licenses that permit it, or the feature needs a different access path.
+
+See sample: `do-not-grant-rights-beyond-a-users-entitlement.good.al`.
+
+## Anti Pattern
+
+Authoring permission sets in a sandbox with full-license context and shipping them without verifying which entitlement tier customer users actually hold. The sets look complete in test; on a real customer they silently lose rights at runtime and the symptom is "the feature does not work for some users" with no obvious authorization error.