A task record names its agent under config.agent, not config.project #2531

What is observed

A scheduled task's record in ~/.emrg/tasks.yml names the agent it runs as through a config key called project:

- name: journal-editor
  type: journal
  config:
    project: silicon-science-cs
  interval: 1800
  enabled: true

Everyone who touches that key spells it as a string literal, in six places that must agree:

Each is a hand-written literal, so a rename is only as complete as its least visible site — and nothing in the suite fails when one of them keeps the old spelling while the others move. The task simply resolves to no directory and stops scheduling, silently.

What is expected

The key that names a task's agent is agent, spelled that way in the seeded record, in resolution, in the wire field a client sends, in the form the GUI posts, and in the file on disk.

What the fix must satisfy

1. One spelling, no compat read. Resolution reads config.agent. A record carrying config.project is migrated in place at daemon startup rather than read through a fallback: a tree that answers both spellings keeps the ambiguity alive, which is the thing being removed.
2. The migration runs once, from the daemon, and the reader never writes. projects.yml → agents.yml already sets this pattern (emrg/config.py migrate_legacy_registry): called from daemon startup, never from a path the test suite runs, so no suite run can rewrite a host's live table under a daemon still reading the old key. The same separation is required here.
3. Nothing else moves. Every other field, its order and its value copies across unchanged. A record already carrying config.agent is left alone, and config.project is dropped once agent is present so the old word does not survive as a residue.
4. The nine live tasks still resolve. A table in the host's current shape, passed through the migration and then through resolution, must answer the same directory for every task at the same interval — measured read-only, against a copy.
5. Seed, wire and form agree. The scheduler's seed record, the daemon's wire field and the GUI form payload carry the same key, and a task created from the GUI is resolvable by the scheduler.
6. A guard names the requirement. A test asserts the read path performs no write to the table, so "the reader never migrates" is pinned rather than assumed.

Scope boundary

The task's config key only. TaskHandler.status()'s derived project / project_path values, projects_list, and the project picker keep their names here and move in a later rename.