[docs] decision: browser permissions are managed through grant/deny/reset/override helpers

[AutomatedTester]

💥 What does this PR do?

Proposes a design decision record: browser permissions are managed through grant / deny / reset / override helpers.

BiDi exposes one permissions primitive (permissions.setPermission), already surfaced raw in the bindings. This record makes the high-level convenience layer a recorded cross-binding decision — grant (single or list), deny, reset (one/many/all via client-side tracking), an exception-safe override(...) block, plus the low-level set_permission escape hatch — so Java/Ruby/.NET/JavaScript converge on the same names and semantics. It is intentionally a superset of Playwright (which has only grant_permissions + bulk clear_permissions).

There is a working reference implementation reviewers can see in action: #17631 (the Python high-level permissions API). This ADR links to it from the binding-status table so the exact shape is visible.

🔧 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/0007-*.md).
• Records one open cross-binding question for review: the CDDL marks origin as required, but the Python reference ([py] Add high-level BiDi permissions API #17631) currently defaults it to None and omits it when absent (spec-non-conformant, browser-dependent). The record's normative rule is that every binding must require origin or adopt one documented default; the resolution should flow back into [py] Add high-level BiDi permissions API #17631.
• 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 CDDL-validated review of the Python permissions implementation in [py] Add high-level BiDi permissions API #17631 against the W3C Permissions BiDi extension and Playwright; revised through discussion and review
  • I reviewed all AI output and can explain the change

💡 Additional Considerations

Completes the set of BiDi ergonomics decision records proposed together (#17671–#17676). Unlike the others, this one already has a code PR (#17631) to anchor it. Cross-binding convergence is tracked in the binding-status table.

🔄 Types of changes

• Documentation (design decision record)

[diemol]

Shouldn't we agree on #17681 and #17671 before reviewing this?

[AutomatedTester]

Shouldn't we agree on #17681 and #17671 before reviewing this?

Probably but the idea of sharing all my ideas is to show how I have thought through all the different layers

[AutomatedTester]

Following up now that the layering is written down: I've opened #17709 ("BiDi is exposed in three API layers"), the foundational decision this and the rest of the series sit under. As I said above, I shared everything at once to show the layered thinking — #17709 makes that explicit, with #17681 (browsing-context handles) and #17671 (events) being the other two foundational ones.

In that model this permissions ADR is a Layer 2 module decision (I've noted that in its Context), so I'm happy to defer detailed review here until #17709 / #17681 / #17671 settle. One tie-in already in place: the user_context argument here cross-references #17681, where the isolation unit is defined.