Sync routes snapshot: drop sign_up company routes

Mirrors the route removal in gitlab-org/gitlab!253445 (merged), which removes CompanyController and its four registration routes:

• /users/sign_up/company
• /users/sign_up/company/new
• /o/:organization_path/users/sign_up/company
• /o/:organization_path/users/sign_up/company/new

This is case 1 in adding-gitlab-routes.md: the routes already matched /:ROUTE/* and /o/:ORGANIZATION_PATH/*, and they are being deleted rather than added, so src/routes.ts and src/generated_route_guards.ts are unchanged. Only the two snapshots move, and the diff is deletions only. npm test is green (34 files, 367 tests).

Built from main, not from a GitLab ref

main is currently ahead of gitlab-org/gitlab@master by six routes from three pre-landed syncs, all merged today:

Route(s)	Router MR	GitLab side
/api/:version/integrations/jira_forge/user_delegation	fee6d2da	not yet on master
/api/:version/orbit/{context,grep,skills,skills/:name}	0bba3aab	not yet on master
.../merge_requests/:merge_request_iid/cancel_auto_merge	!1354 (merged)	gitlab!255702, open

A plain npm run download-gitlab-routes -- 593995-remove-company-controller writes GitLab's file verbatim and would therefore revert all six. So this snapshot is instead main's current file with only the four company routes deleted. Verified byte-exact: strip those six routes back out and the result is identical to the verbatim download from the GitLab branch.

This does not unblock gitlab!253445 on its own

cells-routes:router-in-sync compares the two snapshots for byte equality. main is the union of several in-flight GitLab branches, which corresponds to no GitLab ref, so the gate is currently red for every GitLab MR that touches routes — gitlab!253445 and gitlab!255702 both included. Merging this MR removes four dead routes from the mirror, which is correct and worth doing, but gitlab!253445's gate only goes green once master has caught up on all six routes above.

Open for review. The diff is final unless main moves again, and it rebases cleanly when it does — the four deletions sit in the /users/sign_up/ and /o/ regions, while every other sync adds routes under /api/.

One note on timing rather than on the diff: merging this before gitlab!253445 lands changes which MRs are red without making any of them green, because the four routes are still on master. After gitlab!253445 merges they become router-only drift counted against every branch, and this MR is then a strict reduction in drift for everyone, gitlab!255702 included. Merge whenever suits the team — nothing here regresses, it is only more useful later than sooner.

Flagging the broader point for the cells team: with the gate blocking as of 2026-09-23, every router MR that pre-lands a route reddens the gate for every other in-flight GitLab route MR, and the only way to drain the backlog is pipeline:skip-router-sync. A subset check — every route on the GitLab branch must exist in the router snapshot, router-only extras allowed — would not have this property, and SnapshotComparison already computes gitlab_only and router_only separately.