feat: discover repos one level deeper inside grouping folders

[Orellius]

What

discover_repos scans exactly one level under repos_dir, so a layout like code/<category>/<repo> discovers nothing: the category folders are not git repos, and the repos below them are never reached. This PR treats a direct child that is NOT a git repo as a grouping folder and scans its children once more.

Guardrails to keep the list clean and the scan cheap:

• a child that IS a repo is taken as-is and never descended into (nested clones stay out)
• hidden directories and node_modules are skipped at both levels
• activity sorting and the already-added marker are unchanged

Why

Plenty of people organize a projects dir by category (work/, oss/, clients/...). Today discovery silently returns nothing for them, which reads as broken in the Add Project dialog and the first-run wizard. Two levels covers this shape without recursing into build artifacts.

Testing

• make check-all passes
• Exercised on a real two-level layout (8 category folders, 23 repos): the automation bridge /eval of settingsLoad() -> discoverRepos() returns all 23, activity-sorted, and the Add Project dialog lists them
• Flat one-level layouts behave exactly as before (repo children short-circuit)

No CHANGELOG changes per contributing rules. Happy to adjust naming or fold the skip-list differently if you prefer.

[simion]

Merged, thanks! Verified the two-level scan locally against a temp tree (flat, code/<category>/<repo>, mixed top-level repo + grouping, nested-clone short-circuit, and the hidden / node_modules skip) — all behave as described.

Followed up on main with unit coverage for discover_repos in 5367473 so the grouping logic doesn't regress silently.

One behavior note for anyone reading later: the hidden-dir skip now also applies at the top level, so a repo sitting directly at <repos_dir>/.dotfiles is no longer discovered (it was before). Niche, and a fine tradeoff for keeping the descent cheap, just calling it out.