[📋 ADR]: BiDi implementation boundaries (#17670)

### Decision record

[docs/decisions/17670-bidi-implementation-boundaries.md](https://github.com/SeleniumHQ/selenium/blob/trunk/docs/decisions/17670-bidi-implementation-boundaries.md) (#17670)

### Binding implementation

Each binding currently exposes the BiDi implementation off the driver and fails conformance;
bringing it in line is a deprecation-policy change, not a straight removal.

- [ ] Java — _PR_
- [ ] Python — _PR_
- [ ] Ruby — _PR_
- [ ] .NET — _PR_
- [ ] JavaScript — _PR_

### Notes

Scope per binding (from the record's "Current behavior" table — what conformance requires):

| Binding | Non-conforming today | Convergence target |
|------------|----------------------|--------------------|
| Java | Driver exposes the raw BiDi connection (`HasBiDi.getBiDi()`); protocol types are public | Deprecate `HasBiDi.getBiDi()`, mark protocol types internal, reach the low-level layer only by composing it with the driver |
| Python | `driver.network` / `driver.script` return the low-level `bidi`-namespaced modules | Return protocol-neutral wrappers from `driver.network` / `driver.script`; mark the `bidi` modules internal |
| Ruby | Driver exposes a BiDi accessor (`driver.bidi`) | Deprecate `driver.bidi`; expose the low-level layer only via composition (`BiDi::Protocol::Network.new(driver)`) |
| .NET | Driver extension returns a BiDi type (`AsBiDiAsync()` → `IBiDi`) | Internalize the BiDi type; reach it by composition, not off the driver |
| JavaScript | Driver exposes a BiDi accessor (`driver.getBidi()`) | Deprecate `driver.getBidi()`; expose the low-level layer only via composition |

Marking a surface *Beta* does not satisfy decision 2 — Beta signals an API becoming supported,
the opposite of internal — so Beta is not an acceptable "internal" convention in review.

Related, tracked separately: all bindings expose a BiDi-named enable option (`enableBiDi` /
`enable_bidi`) that the record notes should become protocol-neutral. This overlaps the open
`enable_sockets` naming discussion, so it is deliberately not checklisted here — it belongs to
whichever record settles that naming.

Start with docs/decisions/17670-bidi-implementation-boundaries.md, especially its Current behavior table and conformance requirements. Then inspect the binding APIs named in this issue: HasBiDi.getBiDi(), driver.network, driver.script, driver.bidi, AsBiDiAsync(), and driver.getBidi(). Done means the applicable surfaces are deprecated or internalized and each binding conforms to the decision without using Beta as an internal convention.

Written by the indexing model from the issue text.