Grant a role binding to a service account

Grants the service account a role at a subscription- or project-level scope (UI "Add binding" on the detail Bindings tab). Reuses the human-user role-assignment machinery: the same catalog role-assignment store, the same role ids (built-in owner/contributor/reader/billing-ops or a custom rol_… id) and the same scope model. The granted access takes effect immediately (an iam.assignment.changed event converges the enforcement caches). Validation: the account must exist and be visible in the scope (else 404 NOT_FOUND); roleId must name a grantable role (else 404 NOT_FOUND); scopeName must resolve to a subscription or project reachable in the scope (else 404 NOT_FOUND); caller must hold a role-management role (owner|admin) else 403 FORBIDDEN. Async & state: synchronous grant — 201 with the created binding. A terminal SUCCEEDED audit Operation is recorded and the account's bindingCount counter updates immediately. Errors: 401 unauthenticated; 403 lacks role-management permission; 404 unknown account, role or scope; 500 grant failure. Idempotency/Concurrency: Idempotency-Key is optional; when sent it is reserved atomically (single-winner) — replaying the same key returns the byte-identical binding and never grants twice; re-granting the same role+scope is an idempotent no-op that returns the existing binding.

Step-up: granting an owner-ranked role (built-in owner, or a custom role that ranks as owner) from a console session whose account has two-factor authentication needs the factor verified in the last 5 minutes, otherwise 403 MFA_STEP_UP_REQUIRED (verify with POST /auth/step-up, then retry). Other roles, and an owner row the member already holds, are not affected.