Avoid Public Event publisher

[Kilian Seizinger (pri-kise)]

Review agents repeatedly recommend making an event publisher public so dependent extensions can subscribe, but the access modifier governs who may raise the event, not who may subscribe — only the object needs to be public, and a public publisher becomes a caller contract that cannot be narrowed after release.

Adds a community knowledge article for that choice (local when only the declaring object raises it, internal behind a public facade) plus samples, and drops the incidental public from four existing Microsoft-layer publishers that are raised only from their own codeunit.

[Jesper Schulz-Wedde (JesperSchulz)]

The core distinction between raising and subscribing is correct, but the detection rule is currently broader than the anti-pattern.

A public event publisher can be deliberate when external callers are intended to raise it—an event-bus/facade API, for example. Detection: ... no local or internal modifier would teach agents to flag every such contract even though Best Practice says to use the narrowest modifier that still permits the intended raisers.

Please scope the finding to publishers made public solely for subscriber access, or cases where repository/API context shows no external raising contract is intended. Explicitly preserve intentionally public raisable events as a valid exception. The incidental sample cleanups and the local/internal subscriber-access explanation otherwise look sound.

[Jesper Schulz-Wedde (JesperSchulz)]

Pushed the scoping change to the branch myself rather than sending it back — it was a one-line concern.

Detection now reads: a public publisher although every raiser is in its own app, with an explicit carve-out for a publisher deliberately made public so another app can raise it, and an instruction to treat the modifier as intentional when context does not settle it. Best Practice also gained a third bullet for that cross-app hub case, so the two sections no longer disagree.

The rest of the PR stands as written — the raise-vs-subscribe distinction is right, and the four sample cleanups are all publishers raised only inside their own codeunit. Good addition, thanks.