A form that scaffolds a derived field passes template-drift, then generates a violating document every time

`templates.rows()` checks a form's **shape** against the contract: a `many` field scaffolded as a list, a scalar as a scalar, a required field present at all. It does not check whether the form scaffolds a field the scheme **derives**.

That case is worse than the one the check was written for, and the module's docstring already contains the principle that covers it:

> **Required fields only, for absence.** … An optional field that *is* scaffolded is checked for shape all the same — absent is a choice, **present-and-wrong is copied**.

A derived field in the form is exactly present-and-wrong-and-copied.

## Reproduction

Against a record where `SOTA.published` is declared `derive = "{published}"` / `from = "source[0]"` (`#233`), add the derived field to the practice form:

```diff
date: '2026-01-01'
+ published: '2020-01-01'
```

```
$ luria lint
exit: 0 # ← the form is clean
```

Then use the form:

```
$ luria new sota --title "A scaffolded derived field"
record/practices.d/SOTA-tmpbpp1u.md

$ luria lint
luria: 2 violation(s)
record/practices.d/SOTA-tmpbpp1u.md: `published:` is written in frontmatter, but
SOTA derives it (`{published}` from `source[0]`) — the value has one source and
this is not it; drop the line and order the fields it reads to say it
```

## Why this is worse than the drift the check was written for

The docstring's motivating case produced documents the lint called **clean** — "legal input in the wrong shape", inert capability, nobody notices for three weeks.

This produces documents the lint calls **dirty**, on a line the contributor never typed. And the finding names the *document*, so the obvious fix is to delete the line from the document — leaving the form untouched to do it again to the next person. That is the workflow bug `CLAUDE.md` names directly:

> A guard that keeps catching you is a bug report about the workflow. One catch is the net working; the same catch twice means the hazard is upstream, and the fix is to remove what generates the mistake, not to keep thanking the net.

Here the form *is* what generates the mistake.

## Suggested shape

One more row in the same check, and it meets the bar for the lint rather than a report — always wrong, mechanically decidable, and the remedy is a deletion:

> `_template.md`: `published:` is scaffolded but `SOTA` derives it (`{published}` from `source[0]`) — every document copied from this form starts in violation; drop the line.

`Contract.derivation(name)` already answers "is this field derived", so the data is in hand.

## Found by

Adopting `#233` in `dmarx/anthology-of-the-sota`. Declaring `published:` required on `LIT` made template-drift fire correctly for the *absence* case — the form did not scaffold a now-required field, and the check said so immediately. I then wrote the mirror by hand into the practice and reading forms (a comment saying the field is derived, don't add it) and only afterwards tested whether luria would have caught the mistake it was warning against. It would not.

Start at templates.rows(), then inspect Contract.derivation(name) and the existing template-drift checks. Reproduce the issue with a form that scaffolds SOTA.published and run luria lint before and after luria new. Done means the form is reported as invalid because it scaffolds a derived field, preventing generated documents from starting in violation.

Written by the indexing model from the issue text.