fix(config): reject malformed github repo slugs in validateConfig

[aniruddhaadak80]

Summary

Tightens validateConfig's GitHub repo check, which previously accepted anything containing a /. Values like "owner/", "/repo", "a/b/c", "owner//repo", and whitespace-padded slugs passed validation and failed later inside gh calls with obscure errors.

• src/core/config.ts:889-899 — replaces the repo.includes('/') check with an anchored owner/repo pattern (/^[A-Za-z0-9_.-]+\/[A-Za-z0-9_.-]+$/): exactly one slash, no empty segments, no whitespace. Error message unchanged (Invalid GitHub repo format ... (expected: owner/repo)).
• src/core/config.test.ts:689-706 — regression tests rejecting owner/, /repo, a/b/c, padded/double-slash variants, and accepting dotted/dashed/underscored names.

Reproduced before the fix via validateConfig probe: all of owner/, /repo, a/b/c, owner/repo␣, ␣owner/repo, owner//repo, / returned valid=true. After the fix all return valid=false, while owner/repo1, my-org/my.repo-1_2, a/b remain valid.

Related issue

No open issue exists (the repo currently has zero open issues). Proactive hardening discovered by scanning the config validation path (src/core/config.ts:889-899) — the gap between what validateConfig accepts and what the GitHub/CI monitoring code can actually use.

Type of change

• Bug fix
• New feature
• Refactor / chore
• Docs

Checklist

• npm run lint passes (no warnings on touched files)
• npm run typecheck passes
• npm run build passes (unaffected; type-only change shape)
• npm test passes for the touched area (src/core/config.test.ts: 53 passed; 1 pre-existing Windows-only failure in parses and process-locks the strict companion contract — fails identically on clean main because resolve('/run/...') differs on Windows, unrelated to this change)
• Docs updated if behavior changed (error message unchanged; no docs needed)
• Commits follow Conventional Commits