Two mentions pasted with nothing between them find neither

Found while reviewing [#564](https://github.com/akiomik/nostui/pull/564). Pre-existing — the pattern that preceded #564 returned nothing here too.

## What happens

```rust
// verified against the current implementation
let adjacent = format!("{npub_uri}{note_uri}"); // no separator at all
assert_eq!(Reference::find(&adjacent).len(), 0);
```

Not one reference — zero. The first URI's trailing boundary fails because the next character is the `n` of `nostr:`, an ASCII word character, and the second URI's leading boundary fails for the same reason from the other side.

This is the same class as the one-space bug #564 fixes, with the separator count taken to zero.

## Why #564 did not fix it

A word boundary cannot tell "this URI runs on into a longer bech32 token" from "this URI is followed by another URI" — both are a word character after the 58th. Distinguishing them needs a lookahead, and the `regex` crate has none:

```
Regex::new(r"(?:(?-u:\b)|(?=nostr:))")
// Err("regex parse error: look-around, including look-ahead and look-behind, is not supported")
```

So closing this means giving up the trailing assertion and checking the following bytes in Rust instead — the URI is valid if what follows is not `[a-z0-9]` **or** begins another `nostr:` URI. That is a scanner rather than a pattern, which is why #564 left it alone rather than growing the regex.

## Worth weighing before doing it

Clients separate mentions with whitespace, so this shape mostly arises from programmatic concatenation rather than from typing. It may be cheaper to fix alongside #566, which pushes `find` toward returning spans and rejected matches and therefore toward scanning anyway, than to hand-roll the boundary on its own.

## Acceptance

- `format!("{npub_uri}{note_uri}")` finds two references, in order.
- `nostr:npub1…foobar` and `foobar_nostr:npub1…` stay rejected.