Align Pay-to Name 2 editability with the other pay-to address fields on purchase documents

[Franco111000]

What & why

On the Purchase Quote, Purchase Order, and Purchase Invoice pages, "Pay-to Name 2" is only editable when the Pay-to option is "Another Vendor". Every other field in the pay-to address group (Address, Address 2, City, County, Post Code, Country/Region Code, Contact No., Contact) is editable when "Custom Address" is selected or when the pay-to vendor differs from the buy-from vendor. The field was missed when that editability logic was applied to the group. This is the purchase-side counterpart of #8312, fixed for sales in #9096.

This change gives "Pay-to Name 2" the same Editable and Enabled expression as the rest of the group on those three pages. The country layers that carry copies of these pages (APAC, BE, CH, DACH, ES, FI, IT, NA, NL, NO, RU) receive the identical two-property change, following the established practice of propagating W1 fixes to the localization layers.

Linked work

Fixes #9097

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

• Extended the three existing pay-to editability tests (CustomAddressPayToOptionOnPurchaseQuotePage, ...PurchaseOrderPage, ...PurchaseInvoicePage in UTPageActionsControls.Codeunit.al) so they now also assert that "Pay-to Name 2" is editable when "Custom Address" is selected, alongside the sibling address fields they already cover.
• Verified that every page copy across the localization layers received the identical two-line change and nothing else (the diff is uniform, and byte order marks and line endings of the touched files are preserved).
• Confirmed on the Purchase Header table that "Pay-to Name 2" is a plain text field with no OnValidate logic and no table relation, so widening its page editability has no side effects beyond allowing input.
• I did not build the Base Application locally; the change is limited to two page control properties per page, replicating the exact expression already used by all sibling fields, and relies on the extended test coverage in CI.

Risk & compatibility

• The Blanket Purchase Order, Purchase Credit Memo, and Purchase Return Order pages are intentionally not touched: they have no PayToOptions-based conditions on this field, mirroring the scoping decision on the sales-side issue.
• No breaking changes: no object signatures, events, or table schema are affected.