[docs] decision: browsing contexts are exposed as handle objects

[AutomatedTester]

💥 What does this PR do?

Proposes a design decision record: browsing contexts are exposed as handle objects.

Working with multiple tabs/windows over BiDi is awkward because there is no object representing a single browsing context — every operation is called on one shared module instance and takes the context id explicitly (browsing_context.navigate(context=id, ...)). For parallel work this means each worker repeats context= bookkeeping against shared state, with no per-tab unit to own. This record proposes a per-context handle object (returned by create/get_tree/expect_page) that carries the per-context operations as methods and scopes events to that context — matching the Playwright model where operations live on the object, which is exactly what makes one-context-per-worker parallelism clean. The flat module API stays as the compatibility surface.

🔧 Implementation Notes

• Follows the docs/decisions/ process from [docs] add design decision record process and template #17665 — depends on [docs] add design decision record process and template #17665 landing (adds only docs/decisions/0008-*.md).
• Builds on the expect_* primitive ([docs] decision: BiDi events are awaited with expect_* context managers #17671) for expect_page/expect_popup.
• States a concurrency contract (one driver drivable from multiple threads, one context per thread) but leaves the enabling transport correctness as a per-binding internal with its own tests — not decided here.
• Records two follow-ups: exposing the user context as a grouping object (≈ Playwright BrowserContext), and fixing per-context event-subscription scoping.
• A full asyncio-native Page model is explicitly out of scope (its own RFC). No wire-protocol change.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code
  • What was generated: Initial draft of the decision record, derived from a review of the current browsing_context surface and BiDi transport against Playwright's object/concurrency model; revised through discussion and review
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

Extends the set of BiDi ergonomics decision records (#17671–#17677) with the parallelisation/object-model concept. The cross-binding name of the handle (Page-like / Tab / BrowsingContextHandle) is part of what's being decided. Cross-binding convergence is tracked in the binding-status table.

🔄 Types of changes

• Documentation (design decision record)

[nvborisenko]

browsing_context here is still verbose, simple accessor for couple of methods even without internal state... Can be simplified:

tab = driver.new_tab(...)
ctx = driver.new_context(...)
ctx.new_tab(...)

tab, context here is an example of alternate names, honestly for me as for end user it is not obvious what is BiDi's browsingContext and userContext. Tab or Page is cleaner.

[AutomatedTester]

For the most part, I don't think users should need to understand contexts which is why I call it "isolation" in terms of browser context we already have the switchTo APIs which we can extend to understand isolation.

I don't really want too much on driver as we can head into the space of creating a god object which is worse.

[AutomatedTester]

I think for the most part the UserContext doesn't need to be surfaced to the user. I would for the verbose case have this and for a more succinct API that allows people to do whatever they want