Align the Vend. Entry-Edit post-modify event with its Cust. Entry-Edit counterpart

[Franco111000]

What & why

Codeunit 113 "Vend. Entry-Edit" raises OnRunOnAfterVendLedgEntryMofidy after the vendor ledger entry is modified. The event name is misspelled, and it only exposes the modified entry. Its counterpart in codeunit 103 "Cust. Entry-Edit", OnRunOnAfterCustLedgEntryModify, passes both the record given to the codeunit and the modified entry, so vendor-side subscribers get less context than customer-side subscribers for the same hook point.

This change adds OnRunOnAfterVendLedgEntryModify with the exact shape of the customer event (both records passed by var, XML documentation mirroring the customer wording) and obsoletes the misspelled event with the standard #if not CLEAN29 pattern. The misspelled event is still declared and raised until cleanup, so existing subscribers keep working and get the usual obsolete warning pointing to the replacement. The country layers that carry full copies of the codeunit (APAC, CH, IT, NA, NL, NO, RU) receive the identical change, following the established practice of propagating W1 fixes to the localization layers.

Linked work

Fixes #8316

How I validated this

• I read the full diff and it contains only changes I intended.
• I built the affected app(s) locally with no new analyzer warnings.
• I ran the change in Business Central and confirmed it behaves as expected.
• I added or updated tests for the new behavior, or explained below why none are needed.

What I tested and the outcome

• Verified the new event signature is a one-to-one mirror of OnRunOnAfterCustLedgEntryModify in codeunit 103: first parameter is the record passed to the codeunit, second is the modified entry, both by var, raised immediately after Modify().
• Searched the whole repository for references to OnRunOnAfterVendLedgEntryMofidy: the only occurrences are the declaration and the raise in the eight copies of the codeunit itself. No app or test subscribes to it, so the obsoletion cannot break in-repo code.
• The obsoletion follows the pattern already used in the repository for replaced events (obsolete attribute and old raise wrapped in #if not CLEAN29, new event raised unconditionally), for example OnBeforeCalculateAndGetPlanningCompList in CalcItemPlanPlanWksh.Codeunit.al from the 27.0 wave.
• Confirmed the diff is uniform across W1 and the seven layer copies and contains only the two blocks per file (call site and event declarations).
• No tests added: the change is an additive integration event plus a guarded obsoletion, with no behavior change when no subscriber is registered. The customer counterpart event has no dedicated test either.
• I did not build the Base Application locally; the change is event-only and relies on CI for compilation across all layers.

Risk & compatibility

• No breaking change: the misspelled event remains declared and raised until CLEAN29, so external subscribers keep working while the obsolete warning steers them to the replacement.
• The new event is raised at the same execution point as the old one, right after Modify() and before Rec := VendLedgEntry, so both events observe the same record state.
• None beyond that: no object signatures, table schema, or permissions are affected.