fix(document): a wikilink's display text is not part of its target

[ewiger]

[[link-op|link operator]] is one reference with display text, as
hypermarkdown.hmd states — "all of which may carry
display text as [[target|display text]]" — and as
doc-type.hmd repeats: "Display text declares
nothing."

The collector took the whole bracketed string as the target, so that link became
a node named link-op|link operator sitting beside the real link-op. Querying
this repository's own wiki showed it:

option-type → link-op
option-type → link-op|link operator

Thirty-three such links across doc/, fourteen distinct phantom nodes.

The change

split_once('|') on the bracketed text, taking what precedes the bar. A later
bar is display text too, which is why it is split_once and not split.

Duplicates needed no work

build_edges already identifies a link edge by its endpoints and merges the
annotations across every place the link is written. The wrong target was what
prevented that from applying. A card writing both forms of one link:

First [[beta]] {weight: 1} then again as [[beta|the second one]] {note: "same edge"}.

source  target  data
alpha   beta    {note: "same edge", weight: 1}

One edge, both annotations merged. Two edges to two nodes before.

Document.references still holds one entry per written occurrence, in document
order, since that is what makes the merge downstream possible.

Tests

Three beside the code in src/document.rs: display text stripped from the
target including spaces around the bar, an annotation still binding through
display text, and [[|just words]] naming nothing rather than yielding an empty
target.

Not in this change

A [[link]] written inside a fenced code block is still collected as a
reference, so the syntax examples in the wiki's code blocks remain phantom nodes
— alice and nowhere are still in that query's output. That is a behaviour
change with a design question behind it and belongs on its own.