scheduler_with_persistence computed inconsistently between init and add

[lbedner]

What

scheduler_with_persistence is computed two different ways depending on which code path sets it, so the same stack gets different values from aegis init vs aegis add.

Path	Expression	postgres backend
aegis/core/template_generator.py:245 (init)	scheduler_backend != MEMORY	True
aegis/commands/add.py:599 (add)	scheduler_backend == SQLITE	False
aegis/core/copier_updater.py:115	scheduler_backend == SQLITE	False
copier.yml:176 (question default)	scheduler_backend == 'sqlite'	False

So aegis init --components scheduler[postgres] writes scheduler_with_persistence: true, while aegis add scheduler[postgres] writes false. Classic init-vs-add divergence, the #814 bug class.

Why it is currently harmless

The flag is vestigial. Nothing reads it to make a decision:

• No template branches on it — the only hit under {{ project_slug }}/ is .copier-answers.yml.jinja, which just echoes it back.
• No Python reads it; every reference in aegis/ is a write.
• template_generator.py even labels it "Legacy scheduler persistence flag for backwards compatibility".

The thing that does gate scheduler persistence files is a separate, correct check in get_component_files (backend_variant in (SQLITE, POSTGRES)), which is equivalent to != MEMORY.

Why it is worth fixing anyway

It is a loaded gun for anyone who reasonably assumes the flag means what its name says. Found during RD-06 (#921) while looking at whether scheduler's FileManifest.extras gating could be collapsed onto this key and the ComponentNames.SCHEDULER special case in get_component_files deleted. It can't — doing so would have propagated the divergence into which files get written, turning a dormant inconsistency into a real one. That special case stays in place because of this.

Options

1. Unify on != MEMORY (matches init, matches the real persistence gate, matches the name) and fix the two == SQLITE sites plus the copier.yml default. Smallest change, makes the flag mean what it says.
2. Delete it. Nothing reads it. It only survives in .copier-answers.yml for backwards compatibility with projects that already have it; aegis update's answer reconciliation would need to tolerate its absence.

(1) is the safer near-term fix and unblocks collapsing the scheduler special case later. (2) is the honest end state if nothing ever needs it.

Acceptance

• One expression, one meaning, asserted by a test that generates a postgres-backed scheduler both ways and compares the flag.
• If (1): the ComponentNames.SCHEDULER branch in get_component_files becomes collapsible onto the flag — worth re-checking then (see RD-06 · Post-render hooks for non-diffable transforms (Pattern D) #921's note on subtractive extras, which is the other half of that problem).