[Service Bus] Fix batch send of messages with routing properties (#47625)

* [Service Bus] Fix batch send of messages with routing properties

Sending a batch of messages with message_id, session_id, or partition_key
set raised TypeError ("'BatchMessage' object is not subscriptable") on the
uamqp transport, and surfaced a secondary AttributeError on the list send
path.

- Route batch-envelope property capture through a new transport abstraction
  (set_batch_envelope_properties) with pyamqp and uamqp implementations, so
  routing properties land on the AMQP batch envelope on both transports.
- Discriminate the batch path from the single-message path with an explicit
  isinstance(list) check instead of a broad except TypeError that masked the
  real error.
- Add unit coverage for the envelope capture on both transports and for the
  list-vs-single discriminator contract.

Regression from #42598.

* fix: Use inline pylint disable for protected-access in batch send

- pylint 4.0.4 does not honor a standalone disable comment inside an else
  suite (only inside an except suite), so converting the try/except to
  if/else left two protected-access warnings on _message unsuppressed
- Move the disable inline onto the _message accesses in both sync and
  async ServiceBusSender.send_messages, matching the existing file
  convention

* chore(servicebus): add api.md and api.metadata.yml for API review gate

---------

Co-authored-by: Eldert Grootenboer (from Dev Box) <egrootenboer@microsoft.com>

Author: EldertGrootenboer

sdk/servicebus/azure-servicebus/CHANGELOG.md

@@ -6,6 +6,7 @@
 
 - Fixed a bug where messages returned by `receive_deferred_messages` had a `lock_token` of `None`, which prevented settling (completing, abandoning, dead-lettering, deferring) or renewing the lock on a deferred message in `PEEK_LOCK` mode. The lock token is now read from the `lock-token` field of the management-link response for deferred messages. ([#42454](https://github.com/Azure/azure-sdk-for-python/issues/42454))
 - Read `com.microsoft:max-message-batch-size` vendor property from the AMQP sender link to correctly limit batch size on Premium large-message entities, where `max-message-size` can be up to 100 MB but the batch limit is 1 MB.
+- Fixed a bug where sending a batched or multi-message payload with `uamqp_transport=True` raised `TypeError: 'BatchMessage' object is not subscriptable` (and a masked `AttributeError` on the list path) when the first message carried a `message_id`, `session_id`, or `partition_key`. The batch envelope properties are now set through the transport-appropriate code path. (regression from [#42598](https://github.com/Azure/azure-sdk-for-python/pull/42598))
 
 ## 7.14.3 (2025-11-11)