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.

Bắt đầu bằng cách đọc Change API và các parser được tham chiếu: submitqueue/entity/github/change_id.go, submitqueue/entity/phabricator/change_id.go và submitqueue/extension/changeprovider/github/validate.go. Xem lại PR #197 và cuộc thảo luận về core/fakemarker trước khi so sánh các tham số truy vấn, fragment và một trường Change có kiểu. Được xem là hoàn tất khi đã giải quyết các câu hỏi về phạm vi, hình dạng và tính tổng quát, đồng thời ghi lại hoặc triển khai thiết kế đã chọn mà không làm hỏng việc xác thực change-ID nghiêm ngặt.