This PR promotes the ES Excluded from calculation flag on detailed customer and vendor ledger entries into W1, then adds that flag to customer/vendor balance FlowFields and customer statement dataitems across the propagated layers. The direction is coherent: ES Cartera marks redrawal and rejection detailed entries as excluded, and the promoted filters keep those entries out of balances where ES already did so. The change is still not ready because propagation is incomplete, no W1 regression coverage was added for this financial calculation behavior, and one vendor-side cue remains inconsistent with the rest of the vendor balance changes.

S1 - Fix missing ES layer propagation
Verify App Changes is failing because src/Layers/ES/BaseApp/Finance/GeneralLedger/Setup/GeneralLedgerSetup.Table.al still needs to be integrated. Run the layer propagation and include the generated file so the PR can build and validate.

S2 - Add W1 regression coverage for balances
This promotes financial balance logic from ES to W1, but no test file changed and the PR gives no reason for skipping tests. Add W1 tests that create included and excluded detailed customer/vendor ledger entries and assert the affected balances and statement dataitems ignore the excluded entries.

S3 - Filter My Vendor balance too
table 9151 "My Vendor" still calculates Balance (LCY) from all detailed vendor ledger entries. Vendor redrawal and rejection entries can be marked as excluded, so the My Vendors cue can disagree with the Vendor card. Add the same "Excluded from calculation" = const(false) filter there, or document why that cue should include excluded entries.

Risk: This changes core customer and vendor balance calculations for every W1-derived country layer. The default value is false, so countries that never set the flag should keep current balances, but any code that sets the flag now changes customer cards, vendor cards, ledger remaining amounts, general ledger setup due balances, currency due balances, and statements. The area is financially sensitive, and the current failed propagation check shows the layer set is not yet internally consistent.

Necessity: The change is necessary if ES Cartera behavior is being generalized: excluded redrawal/rejection detailed entries should not inflate normal balances. The scope is mostly right because ES-specific duplicate files are removed and W1 receives the common field and filters, but the PR must finish propagation, cover the new W1 behavior with tests, and fix the remaining vendor cue gap before merge.