Authenticate interaction provenance and remote approvals

## Parent and milestone

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

## Problem

PTY output and repository content are untrusted text. They can imitate an
approval prompt, while a remote user may be unable to distinguish a real
runtime interaction from prompt injection or replayed output.

## Outcome

Define authenticated interaction provenance and enforcement rules that bind
every decision to the current fenced run, source, action, sequence, and expiry.

## Scope

- Record runtime, node, run, lease, sequence, action payload hash, source type,
confidence, expiry, and idempotency identity.
- Distinguish structured runtime interactions from degraded PTY heuristics.
- Define which risk classes can never be approved from heuristic text alone.
- Bind Telegram and future-client callbacks to one authorized interaction.
- Preserve exact action context for audit while applying redaction policy.

## Non-goals

- Replacing Alfred's decision policy.
- Treating a displayed message or Telegram callback token as proof of runtime
origin by itself.

## Acceptance criteria

- [ ] Replay, stale lease, duplicate callback, forged prompt, and source
downgrade fail conservatively.
- [ ] High-risk heuristic interactions cannot become executable approvals.
- [ ] UI/view models display source and degraded state without vendor types.
- [ ] Decision and interaction audit records are immutable and correlated.
- [ ] Structured and PTY regression scenarios are specified.

## Validation

- Adversarial prompt-injection, replay, reordering, and stale-owner tests.

## Dependencies

- #13 interaction audit, #26 normalized runtime events, #41 control API, and
Alfred's future policy contract.

Start by reading the dependency issues #13, #26, and #41, then trace the interaction audit, normalized runtime events, control API, Telegram callbacks, and UI/view-model boundaries described here. Define the provenance and enforcement contract before implementation; done means the listed replay, forgery, downgrade, audit-correlation, and structured-versus-PTY regression scenarios are specified and pass conservatively.

Written by the indexing model from the issue text.