Reference::find tells a renderer neither where a mention was nor that one was dropped

Noticed while reviewing [#564](https://github.com/akiomik/nostui/pull/564). Pre-existing; not worth changing there, because nothing renders NIP-27 yet and the right shape depends on what the renderer needs.

`Reference::find` returns `Vec`, and a `Reference` is `{ nip21, value }`. Two things a renderer will want are missing from that.

## No byte span

Turning a mention into a link means replacing a range of the note with styled text. `find` knows the range — `regex::Match` carries `start()` and `end()` — and throws it away, keeping only the matched string. The renderer would have to search the text again for each `value` to recover what the regex already had, and a note that mentions the same pubkey twice makes that search ambiguous.

## A lexically valid URI that fails to parse vanishes

The pattern accepts `[a-z0-9]{58}` without checking the bech32 checksum, so a mistyped npub matches and then `Nip21::parse` fails. `filter_map` with `.ok()` drops it, and nothing distinguishes that from text that never looked like a mention:

```rust
// verified against the current implementation
let bad = "nostr:npub1f5uuywemqwlejj2d7he6zjw8jz9wr0r5z6q8lhttxj333ph24cjsymjmuh";
assert_eq!(Reference::find(bad), vec![]);
```

Rendering it as plain text is very likely the right behaviour — but it should be a decision the renderer makes, not one the parser makes silently. Today a typo'd mention and ordinary prose are the same thing to the caller.

## Shape

Both point the same way: carry the span on `Reference`, and give the caller a way to see a rejected match rather than a shortened list. Which of the two the renderer actually needs should decide the details, so this is better settled when NIP-27 rendering is wired up than before.

## Acceptance

- A caller can style a mention without searching the note text for it again.
- A URI that matches the pattern but fails `Nip21::parse` is distinguishable from no match at all.