Let a trigger choose its service account role

What does this MR do and why?

Adds service_account_access_level to the flow trigger services, so the dedicated account for an autonomous trigger can join the project at a role other than the default Planner.

The trigger runs unattended, so it may not out-rank either the person configuring it or the flow it runs. The requested role is capped at the lower of the two, and a request above that cap is rejected rather than silently downgraded. When neither role is readable (an instance admin acting outside the project, with a flow account that has no project membership yet), the cap falls back to the default rather than letting the request through uncapped.

Editing a trigger re-levels the account's existing membership.

Related: #594180

Stack

1. !251852 — column and model
2. !253659 — provisioning at the default role
3. This MR — choosing the role, and the ceiling
4. !253636 — serviceAccountAccessLevel GraphQL argument

Testing

Covers the ceiling in both directions: rejected above the flow account's role, rejected above the creating user's role when the flow account out-ranks them, clamped down when the flow account sits below the default, capped at the default when neither role is readable, and accepted at or below the cap.

416 examples pass across ee/spec/services/ai/flow_triggers/, the model spec and the trigger mutations.