Update ADR 008: Duo Messaging Service with adapter consolidation learnings

executors to proxy requests to the GitLab instance for self-managed as

documented below.

#### From messaging services (Slack, Teams, etc.)

The Duo Messaging Service allows users to trigger workflows from external

messaging platforms by @mentioning Duo. It uses the same CI pipeline execution

path as remote workflows but with a different trigger mechanism:

1. User @mentions Duo in a messaging service (e.g., Slack)

2. The messaging service sends an event to GitLab Rails

3. A messaging adapter translates the event into a goal and callback context

4. The orchestrator resolves the user's `duo_default_namespace`, finds or

   creates a `duo-workspace` project, and triggers a `developer/v1` flow

5. The agent runs in CI with the same composite identity as Duo Developer

#### From messaging services and GitLab-native surfaces

The Duo Messaging Service allows users to trigger workflows by @mentioning Duo

from various surfaces — external messaging platforms (Slack, Teams) as well as

GitLab-native surfaces like issue and merge request comments. It uses the same

CI pipeline execution path as remote workflows but with a different trigger

mechanism:

1. User @mentions Duo on a surface (e.g., Slack message, MR comment)

2. The surface sends an event to GitLab Rails

3. A surface-specific adapter resolves all policy decisions — authorization,

   service account, flow selection, project — and packages them into a

   trigger bundle

4. The shared base adapter handles mechanism: composite identity linking,

   SA project membership, callback context enrichment, and delegates to

   `ExecuteWorkflowService` to start the CI pipeline

5. The agent runs in CI with composite identity (intersection of user and

   service account permissions)

6. When the workflow completes, a `CallbackWorker` (subscribed to

   `WorkloadFinishedEvent` via EventStore) delivers the result back through

   the adapter to the messaging service

   the adapter to the originating surface

The adapter pattern allows adding new messaging platforms by implementing a

small interface (~5 methods) without changing the orchestration or execution

The adapter pattern allows adding new surfaces by implementing policy decisions

and a few delivery methods, without changing the shared mechanism or execution

infrastructure.

For the full architecture, see