Percent-encoding is not handled consistently in local reference pointersc #61

Since #60, the workspace registers keys as escaped JSON pointers (~0 / ~1, RFC 6901 §4). It does not percent-encode them. Names recovered from a reference go through JsonPointer.TryFromUriFragment, which does percent-decode (RFC 6901 §6). Because of this mismatch, keys containing % or other characters that have to be percent-encoded in a URI fragment don't round-trip.

Affected cases

1. A 2.x server name containing a literal percent sequence is silently renamed.

servers:
  a%20b: { url: example.com, protocol: kafka }
channels:
  test:
    servers: [ a%20b ]
   The channel's server is written back as a b, with no error.

2. A percent-encoded 3.x $ref resolves to a copy.

servers:
  a b: { host: example.com, protocol: kafka }
channels:
  test:
    servers:
      - $ref: '#/servers/a%20b'

The ref misses the workspace registry (#/servers/a b) and falls back to JsonPointer against the raw document. That deserializes a separate copy of the server, so changes made through the reference don't reach document.Servers["a b"]. An unencoded $ref: '#/servers/a b' resolves correctly.

Scope

Both cases need keys that fail the spec's key patterns, so valid documents aren't affected. Key-pattern violations are reported as errors, but the document is still read, so this applies whether or not validation is enabled.

Possible fix

• Add JsonPointer.ToUriFragment(), the reverse of FromUriFragment: escape each token with ~0 / ~1, then Uri.EscapeDataString.
• In AsyncApiWorkspace.ToLocationUrl, rewrite the fragment of every location into that one format. RegisterComponent, Contains and ResolveReference all go through it, so encoded and unencoded refs would find the same entry.
• Build workspace registrations and the 2.x reader's refs with the same helper instead of concatenating EscapeToken output.
• Add tests for a key containing % and a key containing a space, run through 2.x→2.x, 3.x→3.x, 2.x→3.x and 3.x→2.x, like EscapedReferenceKeys_Should.