Define the pipeline plugin SPI, manifest, and security model

## Parent and milestone

- Parent issue: #24
- Milestone: not scheduled; implementation depends on #14 and starts after #15.

## Problem

An untyped list of prompt hooks would let extensions reorder work
unpredictably, inspect excessive data, remove critical diagnostics, or
interfere with Durex ownership and authorization.

## Outcome

Publish an ADR for typed phases, immutable execution envelopes, versioned
manifests, language-neutral invocation, permissions, ordering, failures,
auditing, isolation, and protocol compatibility.

## Scope

- Define phases from task intake through context, prompt, dispatch, runtime
events, tool results, interactions, finalization, and checkpoints.
- Define plugin manifest fields, capabilities, dependencies, conflicts,
permissions, timeout, bounds, determinism, and per-phase failure policy.
- Define UTF-8 newline-delimited JSON-RPC over stdio for third-party plugins and
one logical interface for built-in plugins.
- Define process framing, request/response limits, cancellation, diagnostics,
and malformed-output behavior.
- Define enforceable operating-system or container isolation for filesystem,
network, process, secret, and resource restrictions. Reject configurations
whose restrictions cannot be enforced.
- Define MCP as an optional context/tool adapter rather than the complete
plugin SPI.
- Define supply-chain, secret, privacy, and threat boundaries.

## Non-goals

- Implementing the plugin host.
- Auto-discovery or automatic package installation.
- Running third-party plugins in the Durex process.
- Treating manifest permission declarations as an isolation mechanism.
- Allowing plugins to mutate task identity, leases, fences, authorization, or
process ownership.

## Acceptance criteria

- [ ] Ordering and dependency cycles have deterministic validation rules.
- [ ] `fail_open`, `fail_closed`, `fallback_raw`, and `retry_bounded` behavior
is explicit per phase and plugin.
- [ ] Original content, transformation provenance, and raw fallback
requirements are specified.
- [ ] Wire framing, protocol negotiation, and compatibility policy are
documented.
- [ ] Permission declarations map to enforceable isolation or fail
configuration explicitly.
- [ ] Malicious, slow, crashing, oversized, incompatible, and cancellation
conformance scenarios are specified for #34 and #35.
- [ ] Architecture and documentation cross-references are updated; operator
configuration and SDK guides remain owned by #34 and #35.

## Validation

- Threat-model and protocol-fixture review against malicious, slow, crashing,
oversized, incompatible, and sandbox-escaping plugins.

## Dependencies

#14 configuration contract, #23 runtime boundary, and #15 implementation gate.

Start by reviewing the contracts in #14 and #23, then the implementation gate in #15, before drafting the ADR requested here. Define the SPI, manifest, protocol, isolation, failure, and threat-model rules against the listed acceptance criteria; validate them with the conformance scenarios planned for #34 and #35. Done means the ADR and architecture cross-references are complete without taking ownership of the operator or SDK guides.

Written by the indexing model from the issue text.