Harden the metadata transform against long topics and newlines #9

Context

modules/metadata converts each repo's DESCRIPTION.md and TAGS.md into a GitHub description and topic list. It has 6 passing tests and reproduces live GitHub values for 50 of 54 repos, with the 4 exceptions handled by explicit overrides.

Two gaps are real but unreachable with current repository content. Neither is urgent. Both are cheap, and both fail in ways that are annoying to diagnose later.

Gap 1, no guard on GitHub's 50-character topic limit

The module caps topic count at 20 but never checks individual topic length. GitHub rejects topics over 50 characters with a 422, which would fail the apply for that repository.

Longest derived topic today is 32 characters (round-trip-string-json-converter), so nothing currently trips it. A single long tag added to any TAGS.md would.

Gap 2, desc_clean strips carriage returns but not newlines

desc_clean = trimspace(replace(var.description_raw, "\r", ""))

Every DESCRIPTION.md in the org is currently a single line. A future two-paragraph description would embed a newline, split(". ") would not see the .\n sentence boundary, and truncation would silently degrade to the word-boundary fallback instead of cutting on a sentence. The output stays valid, it just quietly gets worse.

Acceptance criteria

• Topics longer than 50 characters are truncated or dropped, with a test using a fixture over the limit
• Newlines are normalized before sentence splitting, with a test using a multi-paragraph fixture
• The existing 6 tests still pass unchanged. Their fixtures are real repository content and their expected numbers are live GitHub values, so altering either destroys the test's meaning.

Lower priority

There is also a whitespace edge case: the fallback returns "" if the first 349 characters are entirely whitespace. That is semantically the right answer for a whitespace-only file and is not worth code.