Add StrongPoint custom knowledge layer

Eight organization rules in custom/knowledge, each overriding or
supplementing the Microsoft layer for StrongPoint repositories:

- style/spu-prefix-on-objects-and-extension-members
- style/cyclomatic-complexity-is-not-a-gate-in-sp-repos (LC0010 = Info)
- ui/keep-tooltips-on-sp-page-fields (AA0218 = Error, LC0064 off;
  overrides microsoft ui/bound-page-field-inherits-source-field-tooltip)
- data-modeling/sp-field-names-fit-30-chars-with-prefix (AL0468 = Error)
- events/change-ls-central-behaviour-through-its-events
- web-services/device-io-goes-through-sp-device-manager
- appsource/sp-id-ranges-are-not-checked-by-as0084 (AS0084 = None)
- upgrade/sp-released-ids-never-change

Sources: sp.ruleset.json across SP repositories, SPUFBUpgrade pattern in
SP-LSC-Fiscal-Printing, observed LS Central and Device Manager usage.
Verified: all eight are indexed by Build-KnowledgeIndex.ps1, and a review
of a probe app applied the ToolTip rule as major and suppressed the
Microsoft article by layer precedence.

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

custom/knowledge/events/change-ls-central-behaviour-through-its-events.md

@@ -0,0 +1,26 @@
+---
+bc-version: [all]
+domain: events
+keywords: [ls-central, lsc, event-subscriber, pos, integration, dependency, false-positive]
+technologies: [al]
+countries: [w1]
+application-area: [all]
+---
+
+# Change LS Central behaviour through its events; calling its public codeunits is fine
+
+## Description
+
+StrongPoint extensions depend on LS Central. To change or extend what LS Central does — POS transaction flow, posting, printing, tender handling — SP code subscribes to LS Central events (`[EventSubscriber]` on `Codeunit::"LSC ..."`) instead of copying or re-implementing LS Central logic. Using LS Central's public codeunits as services is established SP practice and not a defect: `LSC POS Session`, `LSC POS Transaction`, `LSC POS Functions`, `LSC POS Print Utility`, `LSC WS Functions` and similar are called directly across all SP LSC apps.
+
+## Best Practice
+
+When the change alters LS Central's own behaviour, find the LS Central event that fires at that point and subscribe to it; state the event in the review if one exists. Call LS Central public procedures freely for session state, transaction data, printing and web-service helpers. LS Central source is not in Microsoft's Base App corpus — verify LS Central events against the project's `.alpackages` symbols.
+
+## Anti Pattern
+
+Duplicating an LS Central procedure body inside an SP codeunit to change one step of it, or modifying behaviour by re-running LS Central logic after the fact when an event exists. Equally wrong: flagging a direct call to a public LS Central codeunit as an architecture violation.
+
+## References
+
+StrongPoint practice observed in SP-LSC-Fiscal-Printing, SP-LSC-EMV-Integration, SP-LSC-SCO-Integration and SP-LSC-Discount-Management (event subscribers on LSC publishers alongside direct use of `LSC POS Session`, `LSC POS Transaction`, `LSC WS Functions`).