fix: find known resources through empty fragment aliases

[MbappeWU]

A resource registered with Registry.with_resource("urn:foo#", resource) is stored under urn:foo. registry["urn:foo#"] finds it, but get_or_retrieve("urn:foo#") currently misses it and unnecessarily invokes retrieval.

After the existing exact-key lookup, recognize a single empty-fragment alias when checking both known and crawlable resources. Exact constructor keys retain their priority. Unknown resources still pass the original URI to custom retrieval callbacks, and exception references remain unchanged. Nonempty fragments, including strings ending in another #, and percent-escaped # stay distinct.

Validation:

• Complete test suite including the pinned referencing-suite: 813 passed, 132 expected failures, 406 subtests passed; one upstream pytest deprecation warning.
• Original Nox coverage session on Python 3.14: 511 passed, 100% coverage. Python 3.13 tests/coverage and the original style, typing, mypy and docs-style sessions also passed on the same runtime implementation; the later changes strengthen tests only.
• Six initial regressions on unmodified source: three failures and three passing controls. All six pass with this change. Two additional wrong-match guards pass on the baseline and final implementation.
• Native Hatchling/hatch-vcs wheel and sdist, strict Twine checks, and archive integrity/source parity passed. All 14 runtime/typing files and 40 regular tracked sdist files match the proposal; the suite Gitlink is excluded from the distribution.
• A fresh neutral Python 3.14 wheel install passed public API checks for aliases, callback arguments and cache reuse, seeded wrong-resource guards, raw-key precedence, immutable registry state and original exception references.

The local runtime/test results above were completed at 99ce258; 29ebfa5 changes only one changelog sentence, with all runtime and test bytes unchanged. The distributions were rebuilt at 29ebfa5, passed strict Twine and archive checks, and passed the same public API helper from a new neutral Python 3.14 wheel installation.

The first unmodified fork CI run did not pass: 28 jobs succeeded, 14 were cancelled because hosted runners were not acquired, macOS spelling rejected the changelog word discoverable, and the dependent packaging job was skipped. The sentence now uses found by crawling; the spelling check and word list remain unchanged. Local Enchant is unavailable, so local spelling is not counted as passing. The full original CI run at the corrected head now passes all 44 jobs. All 12 Python 3.13/3.14/3.14t/3.15 test jobs across Linux, macOS and Windows ran 511 tests successfully. The coverage job, style, typing, mypy, documentation builders including all three spelling jobs, native builds and final packaging also succeeded. The unchanged shallow-checkout packaging job produced version 0.1.dev1+g29ebfa57b; the local full-history build produced 0.37.1.dev251+g29ebfa57b. Both are validation snapshots. Tag-only publishing steps were skipped, and the temporarily enabled fork schedule was disabled after completion.

Upstream Read the Docs and pre-commit checks pass. Upstream GitHub CI still requires maintainer approval; upstream review, merge and release remain pending.

AI assistance: OpenAI Codex prepared the implementation, regression tests and this description. Implementation and independent code/input reviews used gpt-5.6-luna sub-agents. No human review is claimed by those checks.