Anchored notes existed for two weeks and nothing could write one

`Op::Note { on, text }` shipped at wire code 7 on 2026-07-29. It claims nothing and mints nothing, it resolves from provenance runs at render time so it follows moves including cross-file moves for free, it narrows under edits, and it reports `on_dead` when its content is gone. `ORESNP` version 3 carried resolved notes per file. The forge rendered a notes view over them. No command line surface existed to author one. For two weeks the vocabulary, the resolution machinery, the snapshot field and the read view all existed and the feature was unreachable, which is the exact failure the record names built-but-unreachable: something listed as done with no production caller. It is now closed. `ore note` is the eleventh verb (`ore` commit `965f809`), with three coordinate spellings distinguished by separator alone -- `path:12` for a line, `path:12-40` for a line range, and `path:120..480` for bytes, which is what a file holding NULs must use and where a line coordinate is refused with the byte form offered by name. The path splits on the last colon, so `C:\...` survives. A line's newline belongs to the line it ends, matching `place.rs`, so a coordinate printed by `flags` or `who` pastes straight back in. Bare `ore note` lists every note including the dead ones, which is the part that actually closes the unreachability -- a note whose content moved to another file or was deleted cannot be found by asking about the file it was written against. Zero engine change was needed. `Rendered::span` already turned offset and length into content, and resolution through moves, narrowing and on-dead were all already there, so `fe2o3` was untouched and no Hematite documentation change is owed. Most of the work was learning that the work was already done. One gotcha is worth recording against the feature rather than diagnosing twice: a note only follows content across files when capture recognises a move, and capture's floor is `MIN_MOVE_LEN` at 64 bytes. Cut less than that between files and the log holds a delete plus an insert, so the note correctly reports its content deleted. That is not a note defect. Sixteen new tests, all proved red against deliberately broken code first. One honest correction came out of it: a narrowing test predicted 11 bytes and measured 12, because capture's diff keeps the newline that both versions of an edited line end in. The engine was right and the prediction was wrong. Transcribed from the project record on 2026-08-14. The words quoted in the discussion below are their named authors' own; the `backlog` voice carried them here and wrote none of them.