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.

Commencez par lire la Change API et les parsers référencés : submitqueue/entity/github/change_id.go, submitqueue/entity/phabricator/change_id.go et submitqueue/extension/changeprovider/github/validate.go. Examinez la PR #197 et la discussion sur core/fakemarker avant de comparer les paramètres de requête, les fragments et un champ Change typé. Le travail est terminé lorsque les questions de portée, de forme et de généralité sont résolues et que la conception choisie est documentée ou implémentée sans compromettre la validation stricte de change-ID.