RFC: Define the retirement window for legacy Automation persistence and replay

## Problem

`ScheduledTask` is the current scheduling authority, and no active legacy Automation writer was found. The repository nevertheless continues to maintain legacy persisted-data and replay compatibility:

- Storage detects, migrates, and removes legacy `automation_*` tables;
- RuntimeEvent decoding preserves the `legacy_automation` provenance kind;
- the CLI transcript model and renderer still recognize and display legacy Automation-origin messages.

Verified on local `main` at `ab3c1553a5ad1d0970491c99e6becc18a65ea6aa`.

These readers may be necessary for upgrading old installations and rendering historical transcripts. Absence of a current writer is therefore not a deletion proof. Conversely, without an explicit compatibility horizon, every future scheduling, RuntimeEvent, storage, backup, and CLI change must continue preserving an otherwise retired product model indefinitely.

## Decision required

Define whether legacy Automation persistence and replay are:

1. supported indefinitely;
2. supported through a stated Maka version/date;
3. removable once a verified migration or installed-data condition is satisfied.

The decision should cover these contracts separately where their horizons differ:

- legacy SQLite Automation tables and startup migration;
- persisted RuntimeEvent/session origin values;
- CLI rendering of historical `legacy_automation` messages;
- backup, import, and replay expectations.

## Likely disappearance surface after retirement

If a finite retirement window is accepted and its condition is met, the following may become removable:

- legacy `automation_*` table detection, migration, and cleanup;
- legacy Automation record codecs and projections;
- `legacy_automation` RuntimeEvent/session provenance;
- CLI transcript branches and tests dedicated to the legacy origin;
- associated oversized legacy migration fixtures.

Current `ScheduledTask` storage, execution, recovery, and user-visible behavior would remain.

## Strongest retention reason

Existing user databases or historical transcripts may still require these readers. Removing them without an upgrade-support policy risks making persisted user data unreadable or silently changing transcript provenance.

## Evidence needed for the decision

- [ ] Define the oldest supported upgrade source version.
- [ ] Determine whether deployed databases containing legacy Automation tables remain in scope.
- [ ] Define how long historical RuntimeEvent/session replay must remain readable.
- [ ] Decide whether migration success can be recorded durably so compatibility readers do not remain global forever.
- [ ] State whether old tables/data must remain untouched, be migrated, or may eventually be removed.

## Outcome

This RFC is complete when the compatibility obligation and retirement condition are explicit. A deletion issue should be opened only after that condition is satisfied.

## Non-goals

- Changing the current `ScheduledTask` product contract.
- Deleting or rewriting user data as part of this RFC.
- Reintroducing a legacy Automation writer.
- Combining scheduling compatibility with unrelated Runtime Host protocol compatibility.

## Relevant files

- `packages/storage/src/operational-state-store.ts`
- `packages/core/src/runtime-event.ts`
- `packages/cli/src/pi-transcript.ts`
- current ScheduledTask stores, coordinator, and protocol

---

*This issue was identified and drafted with AI assistance (Codex). A human contributor reviewed the analysis and owns the submission.*

Read packages/storage/src/operational-state-store.ts, packages/core/src/runtime-event.ts, and packages/cli/src/pi-transcript.ts, then inspect the current ScheduledTask stores and protocol. Trace the legacy persistence and replay contracts and document the supported source version, data scope, replay horizon, and retirement condition; the RFC is done when those compatibility obligations are explicit.

Written by the indexing model from the issue text.