`sibling` joins chain components, which is right within a family and destructive across one

## The behaviour

`chains.py` builds weakly-connected components over `relation ∪ sibling`, and the docstring states the intent:

> `sibling` is the **cross-link**, rendered "alongside" — a rival that succeeds nothing still belongs in the family, and joins the component through it.

That is correct for a rival *within* a family. The anthology's Hyper-Connections section is the case it was designed for: Attention Residuals and the Qwen3.8-Next design report succeed nothing, belong in the family, and render as `alongside` at the foot of the section.

It fails when the sibling already belongs to a **different** family.

## Measured, not predicted

In `dmarx/anthology-of-the-sota`, I declared one edge experimentally — `LIT-133 compared_against LIT-045`, Kimi Linear against RoFormer — and regenerated:

| | before | after |
|---|---|---|
| sections on `docs/lineage.md` | 6 | **5** |
| "From Mamba" section | present, 6 members | **gone** |
| "From RoFormer" section | 4 members | **11 members, including Mamba** |

One edge fused the positional-encoding line into the delta-rule line and retitled the result after the wrong root. The edge was reverted — for an independent reason, that it misreads what `compared_against` asserts — but the rendering result stands on its own.

## Why it will keep happening

A cross-family sibling is not exotic; it is what a genuinely comparative paper produces. Kimi Linear runs NoPE against RoPE. Any hybrid architecture paper compares itself against the line it is departing from. The more comparative the literature gets, the more edges there are whose truth is not in question and whose effect on the page is to erase two sections and produce one unreadable one.

The current escape is to not declare true edges, which is the wrong trade — and is exactly what luria#206 refused to do when the renderer asserted false descent.

## Options

1. **`sibling_joins = false`** per chain in `luria.toml`. Cheapest. A sibling then renders `alongside` in *each* family it touches without merging them, so the fact appears twice and the sections stay readable. Duplication in a generated view is not the duplication DP-002 is about.
2. **Components over `relation` only; siblings attach to whichever component their partner is in.** Cleaner conceptually — the spine defines the family, the cross-link decorates it — and it makes a sibling with partners in two families render in both, which is the truth.
3. **Leave it and report.** A finding when a sibling edge would merge two components with distinct roots, so the author sees the cost before it lands. Weakest: it tells you a true edge is expensive without giving you anywhere to put it.

Option 2 looks right and is a behaviour change for existing records; option 1 is the compatible version of the same thing. Worth deciding which before the anthology declares its next comparative edge, because it is currently declining them for rendering reasons.

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

Start in chains.py, then inspect the sibling handling and the generated docs/lineage.md example described in the issue. Read the relevant luria.toml configuration and compare the three proposed behaviours before implementation. Done means the selected policy preserves readable family sections for cross-family siblings and has coverage for the demonstrated component-merging case.

Written by the indexing model from the issue text.