Add default_flow to Duo CLI direct_access response

What

Adds a default_flow object to the Duo CLI direct_access response so the instance can choose the default flow for a new Duo CLI interactive session.

When the caller is the Duo CLI (X-Gitlab-Client-Name: Duo CLI) and the new duo_cli_default_flow feature flag is enabled, direct_access returns:

"default_flow": {
  "flow_config_id": "developer",
  "flow_config_schema_version": "v1",
  "flow_version": "2.0.0-interactive"
}

The field is omitted otherwise, so older clients and non-CLI callers see an unchanged payload (backwards compatible).

Why

Whether the interactive developer flow can run is a property of the instance and its paired AI Gateway, not of a client flag. Moving the decision server-side lets the client stay dumb (no version-checking). See #603623.

The version is carried server-side on purpose: the AI Gateway recently renamed the flow 2.0.0-local → 2.0.0-interactive, which would break any client that hardcoded the version.

Client side

Consumed by gitlab-org/editor-extensions/gitlab-lsp!3682, which deletes the client --developer flag and obeys default_flow.

Feature flag

duo_cli_default_flow (development, default_enabled: false).

Testing

Works locally against Draft: feat(cli): auto-select the flow from the... (gitlab-org/editor-extensions/gitlab-lsp!3682), tested E2E

Related to #603623