Add Finance posting domain-knowledge pilot

[JesperSchulz]

Why

BCQuality has matured into a strong source of review knowledge, but its knowledge corpus today is entirely about writing AL well, not about the Business Central business domain. To help agents not just review but also write correct code, they need domain knowledge too. This PR is a small pilot to test one question before committing to that direction: does BC domain knowledge fit BCQuality's existing remedial/atomic grain, or does it need a new structure?

What

Three atomic domain-rule files under a new community/knowledge/finance/ folder, each encoding a Business Central posting invariant that LLMs reliably get wrong:

• post-ledger-entries-through-posting-codeunits - create ledger entries via Gen. Jnl.-Post Line, never by inserting into G/L Entry directly. Ships a good/bad AL sample pair.
• do-not-modify-or-delete-posted-ledger-entries - posted entries are immutable; correct by reversal, not Modify/Delete.
• write-dimensions-as-dimension-set-entries - the Dimension Set ID is the source of truth, not the legacy global-dimension fields.

Notes for reviewers

• No schema or contract changes. These reuse the existing frontmatter and ## Description / ## Best Practice / ## Anti Pattern shape. finance was already a blessed domain and application-area already existed, so the corpus was effectively built for this.
• Scoped to Type-A (normative) knowledge only. These are rules an agent gets wrong, not descriptive reference (table/field catalogs, flow diagrams). The remedial admission test still gates every file. The .al samples are hand-written and demonstration-only, not derived from BaseApp, per the READ contract.
• Dual-use. Each Anti Pattern is a reviewer check; each Best Practice is a generation instruction. So the pilot improves review today, before any generation skill exists.
• Layer choice. Placed in community/ to follow the documented community -> microsoft promotion path for content that has to prove itself first.
• Passes the repo frontmatter validator (0 errors / 0 warnings) and is discovered by Build-KnowledgeIndex.ps1 with correct metadata.

This is intended as a discussion artifact to evaluate the grain. A couple of open questions it surfaces: the near-redundancy between domain: finance and application-area: [finance] (may warrant a write.md convention note before scaling), and the fact that consuming this for generation is a separate consumption-mode change still to be designed.

[JeremyVyska]

@JesperSchulz - for the Do Not Modify posted entries, should we note in that file that non financial fields can be modified?

For example, Customer Ledger Entries have a wide variety of "operational" fields that are editable these days.

[JesperSchulz]

Good call, thanks Jeremy. You're right that "narrow set" undersold it. I've reworked the file so the immutability rule is explicitly about financial content (amounts, accounts, posting date, quantities), and gave the operational fields their own paragraph in Best Practice -- due date, payment-discount dates, on-hold, applies-to ID, and recipient/communication fields, edited through CustEntry-Edit / VendEntry-Edit and the ledger entry pages that call them. The Anti Pattern already scoped to edits outside the *Entry-Edit routines, so that stays. Pushed in 5e779c7.