Define the Durex-Alfred security integration contract

## Parent and milestone

- Parent issue: #43
- Milestone: not scheduled; design may proceed while implementation remains gated by #15.

## Problem

Durex knows task intent, run ownership, agent lifecycle, interactions, and the
selected execution profile. Alfred observes operating-system effects and is
planned to own policy evidence and decisions. Without a versioned boundary the
two projects could duplicate policy, conflate declared context with observed
facts, alias unrelated identifiers, or create a circular runtime dependency.

## Outcome

Publish a source-pinned architecture contract that assigns ownership for
session registration, observations, policy decisions, approvals, enforcement
receipts, capabilities, identifiers, transport, failure handling, privacy, and
compatibility.

## Scope

- Pin and classify the Alfred capabilities used by the integration.
- Separate declared intent, observed evidence, derived decisions, human
responses, and enforced results.
- Define identifier mappings without reusing Durex or provider ids as Alfred
identities.
- Define observe-only v0 and future bidirectional policy/enforcement phases.
- Define trust boundaries, startup/shutdown ownership, degraded behavior, data
minimization, retention, replay, and backpressure.
- Define conformance scenarios and the follow-up prototype boundary.

## Non-goals

- Implementing the integration or changing current runtime behavior.
- Treating Alfred inotify events as proof of process or agent causality.
- Giving Alfred ownership of Durex queue, retry, process cancellation, agent
routing, Telegram, or workspace provisioning.
- Giving Durex ownership of Alfred observation semantics or policy evidence.
- Defining a public cross-project protocol before one integration is proven.

## Acceptance criteria

- [ ] The contract distinguishes current behavior from planned behavior.
- [ ] Every message family and identifier has one authoritative owner.
- [ ] A trust-boundary and lifecycle diagram is documented.
- [ ] Observe-only failures and future fail-closed enforcement requirements are explicit.
- [ ] Full prompts and secrets are excluded from the minimum shared context.
- [ ] The prototype acceptance criteria are testable against pinned revisions.
- [ ] README, architecture, system overview, and roadmap navigation are updated.

## Validation

- Compare the contract with Durex runtime, supervisor, event, interaction, and
execution-environment boundaries.
- Compare Alfred claims with pinned source, Event Model v0, SESSION_CONTEXT,
observe-ledger, and future policy documentation.
- Run documentation checks and the Durex regression suite.

## Dependencies

- #42 supplies the product positioning.
- #43 owns the security roadmap.
- #44-#47 own execution, interaction, secrets, and artifact contracts affected
by future implementation.

Start by reading the Durex runtime, supervisor, event, interaction, and execution-environment boundaries alongside Alfred's pinned source, Event Model v0, SESSION_CONTEXT, observe-ledger, and policy documentation. Update the README, architecture, system overview, and roadmap navigation with the versioned ownership, lifecycle, trust, privacy, failure, and compatibility contract. Done means all acceptance criteria are documented and documentation checks plus the Durex regression suite pass.

Written by the indexing model from the issue text.