[Service Bus] Settle the public API shape before API review

## Summary

The public surface is unsettled. Thirteen of the open items on #2293 are the same argument about where types live, what is exported, how the builder works, and which fields are public.

## Motivation

The architecture board reviews the public surface once the crate is a release candidate. Reworking the surface after sessions, the rule manager, and the processor are built multiplies the cost, because each of those adds more public types. Settling the shape first makes #4949 through #4956 cheaper.

Open questions from #2293 include the builder, the sub client split, the `SubQueue` surface, `ReceiveMode` copy semantics, `&str` against `&String`, exposed `HashMap` fields, and mutability on the message types.

## Proposal

- Decide the module layout and the re-export list, then apply it.
- Settle the client construction pattern, which is either the current builder or the options bag that the rest of the repository uses.
- Follow the repository convention for options bags, which is public fields with `..Default::default()` rather than sealed structs.
- Name the types after `Azure.Messaging.ServiceBus` where Rust naming allows.
- Write the resulting surface down on this issue so the later feature issues match it.

## Dependencies

Blocked by:

- #4938 [Service Bus] Replace ServiceBusError with azure_core::Error and a failure reason

Sub-issue of #4934.

Start by reviewing the thirteen related open items on #2293 and the current Service Bus public surface. Check the repository's existing options-bag convention, then record decisions for module layout, re-exports, construction pattern, naming, and field visibility so #4949 through #4956 can follow them.

Written by the indexing model from the issue text.