validate: catch config GitHub rejects, before it is merged

[dev-milos]

Found while exercising the organisation features at a larger shape than the release was tested at.

Two kinds of value pass validate today and are rejected only by GitHub, during apply. Apply runs after merge, so by the time the failure appears the config is already on main and every later apply fails until someone pushes a fix. The plan a reviewer sees is clean, so review has no signal to act on.

Team names now fold to the slug, not to lower case

Foo Bar and Foo-Bar both slugify to foo-bar. GitHub does not reject the second — it appends a numeric suffix, and which of the two receives it depends on creation order. The configuration is keyed by name but imported and addressed by slug:

to = github_team.team[each.key]       # name
id = try(each.value.slug, each.key)   # slug

so an unpredictable suffix makes the import ID unpredictable. The existing rule already gave exactly this rationale — "names differing only in case produce the same GitHub team" — it just applied it to case alone rather than to the rest of the transformation. Case-only collisions keep their original message; separator collisions get one naming the derived slug.

Slug derivation was established against the API, not assumed: separators (space, ., /, &) collapse to a single hyphen, underscores survive, Latin accents transliterate, surrounding whitespace is trimmed. Where a name folds to nothing — a fully non-Latin script — the check falls back to the previous behaviour rather than guessing, so it cannot reject a valid pair.

A name that is only whitespace satisfied minLength=1 and reached GitHub, which answers 422 Name can't be blank. Now rejected.

Topics were unconstrained

The schema placed no limit on them. Confirmed against the API:

Sent	GitHub
21 topics	422 A repository cannot have more than 20 topics.
51 characters	422 must start with a lowercase letter or number …
UpperCase, with.dot, topic with spaces	same 422
9lives	accepted — a leading digit is valid

Encoded as maxItems: 20 and ^[a-z0-9][a-z0-9-]{0,49}$ per item.

Verification

• go test ./... passes, existing cases unchanged
• a repo config carrying the three invalid topics above now fails validate with the offending index named, instead of planning clean
• validate and validate-org both run clean against the real gr-oss-developers configuration, including its platform_core and release_engineering teams — no false rejection

repositories.go is one line: the file is not gofmt-clean on main, so reformatting it would have buried the change in ~80 lines of realignment. The schema hook lives in its own file instead.