A signed spine renders unsigned: the chain page never says which relation a step arrived on

## What happens now

`dmarx/anthology-of-the-sota` has adopted #211: both its chains walk `relation = ["extends", "corrects"]`, and eleven edges have moved onto `corrects:` — a work that names a defect in its parent as its motivation, as against one that builds on it.

The pages are byte-identical in shape, which is correct: `_load` unions the spine and the walk cannot tell the two apart, so nesting, ordering and depth are unchanged. But `_step` renders code, title and facets, so **the page says nothing about which relation a step arrived on.** The record now knows that YaRN exists because position interpolation stalls, and that Mamba-2 simply follows Mamba, and the lineage page presents both as the same kind of arrow.

That was an open question in #211 and the implementation deliberately left it out, so the walk could land without a rendering decision attached. This is that decision.

## What it should probably look like

Minimally. The current page renders order, status and title *and nothing else*, on the stated principle that the field carries the sequence and the prose carries the argument — and a sign is sequence, so it belongs, but a whole second tree does not.

The obvious shape is a suffix on the step, in the same register as the existing `— also extends LIT-195`:

```
- LIT-045 — RoFormer: Enhanced Transformer with Rotary Position Embedding (Active)
- LIT-192 — Extending Context Window … via Positional Interpolation (Active) — corrects
- LIT-193 — YaRN: Efficient Context Window Extension (Active) — corrects
- LIT-210 — Round and Round We Go! … (Active) — corrects
```

Questions worth settling rather than assuming:

- **Only the non-default relation, or every one?** Marking `corrects` and leaving `extends` bare reads well and hardcodes "the first relation is the unmarked case", which may not hold for a record whose two relations are peers. Marking both is honest and noisier.
- **What about a step reached by two relations at once?** Possible in principle — a work that corrects one parent and extends another is exactly the case a document facet could not express and this design can. The anthology has none yet. `_render` already handles multiple parents with `— also extends`, so the two mechanisms need to agree on wording.
- **Does `alongside:` want the same?** It names the sibling relation implicitly today. If steps start naming their relation, the cross-links reading `alongside` unqualified becomes an inconsistency (see #210, which may change `sibling` first).

## Why it is worth doing

The sign is currently queryable and invisible, which is the weaker half of what the consumer record adopted it for. Its own curation entry puts it plainly: *"the record knows the difference and the reader of the generated page does not."*

Related: #211 (the spine), #210 (siblings fusing components), `dmarx/anthology-of-the-sota#66`.

_Generated by [Claude Code](https://claude.ai/code)_

Start with the _load, _step, and _render entry points that assemble and display the chain page, then read the decisions in #211 and #210. Settle how single and multiple relations, including alongside links, should be represented; done means the generated page visibly distinguishes the relation a step arrived on without changing nesting, ordering, or depth.

Written by the indexing model from the issue text.