Consider a generic change-URI metadata/augmentation language (Change API)

Context

In #197, the extension fakes inject failures via an ad-hoc sq-fake=<token>
marker embedded in a change URI, parsed by the test-only core/fakemarker
package (Token([]string) / TokenInChanges([]entity.Change)).

Reviewing that PR, @sbalabanov raised two related design questions:

• Should we build a generic augmentation / metadata language into change
  URIs, usable by these fakes and similar tooling — rather than a
  fake-specific marker convention?
• The marker lookup (TokenInChanges) arguably belongs on the Change API
  (entity.Change) rather than living in a test-only helper.

This issue captures that idea as a follow-up so #197 can land as-is (the marker
stays test-only there).

Design considerations

A generic change-URI metadata facility would need to reconcile with the
strict provider change-ID parsers, which today reject anything that isn't a
canonical resource identifier:

• submitqueue/entity/github/change_id.go — requires a full 40-char lowercase
  hex head SHA; a ?key=value query string would not parse.
• submitqueue/entity/phabricator/change_id.go — fixed phab:// form.
• submitqueue/extension/changeprovider/github/validate.go — rejects
  unexpected schemes.

Open questions:

1. Scope — is URI-attached metadata a production capability, or strictly a
   test/example affordance? Putting parsing on entity.Change couples the
   production type to the convention; keeping it in core/fakemarker keeps the
   separation the fakes deliberately maintain ("never production").
2. Shape — RFC-3986 query params (?k=v) vs. fragment vs. a dedicated
   sidecar field on Change. Query params collide with the strict parsers
   above; a typed field avoids string-encoding entirely.
3. Generality — a neutral key → value accessor (e.g.
   Change.URIParam(key)) that fakemarker layers sq-fake semantics on top
   of, vs. a richer metadata model.

References

• PR #197 — fake implementations with error injection
• Threads: the core/fakemarker.go discussion in #197.

Filed as a follow-up per the #197 review discussion. Not blocking.

Start by reading the Change API and the referenced parsers: submitqueue/entity/github/change_id.go, submitqueue/entity/phabricator/change_id.go, and submitqueue/extension/changeprovider/github/validate.go. Review PR #197 and the core/fakemarker discussion before comparing query parameters, fragments, and a typed Change field. Done means resolving the scope, shape, and generality questions and documenting or implementing the chosen design without breaking strict change-ID validation.