Add adversarial examples to the cells routes snapshot

What does this MR do and why?

Add adversarial examples to the cells routes snapshot

The example field in the routes snapshot replaces every parameter with "foo", which contains no dot. Dots are legal inside identifiers (john.doe is a valid username) and are also the Rails format separator (as in /users/sign_in.json). Claim extraction that resolves this ambiguity incorrectly can misroute a request to the wrong cell, and "foo" alone can never exercise that code path.

This adds two optional fields per route. dottedExample is the example rebuilt with dotted parameter values like john.doe instead of foo. acceptsFormat is a boolean marking routes that accept the optional (.:format) suffix. The HTTP Router test suite (the router-side consumer MR) composes the actual suffixed strings itself, as example + ".json" and dottedExample + ".json". The combined case matters: a parser can handle a dotted value alone, or a format suffix alone, and still split john.doe.json at the wrong dot.

{
  "template": "/*namespace_id/:project_id",
  "example": "/foo/bar/foo",
  "acceptsFormat": true,
  "dottedExample": "/john.doe/bar/john.doe"
}

acceptsFormat is a boolean rather than a materialized .json example, because appending the suffix is a constant, not logic. Materializing it would just duplicate every example line and grow the file by roughly 46% for no new information. Only dottedExample needs actual generation logic on this side.

acceptsFormat has to be checked against the raw route specs before normalization strips the (.:format) suffix, since the templates already written to the snapshot have had it stripped. The existing template and example fields are untouched.

References

Parent: gitlab-com/gl-infra/tenant-scale/cells-infrastructure/team#731

Snapshot introduced by: !250481 (merged)

Router-side consumer: gitlab-org/cells/http-router!1290 (merged)

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.