calm-hub: doc/naming accuracy cleanup in GitHub-mode classes

Two unrelated doc/naming nits, grouped since neither has a functional fix and both are low priority.

1. **`GitHubCloneManager`'s javadoc claims parallel cloning; `cloneAll()` is sequential.** Plain `for` loop over `namespaceRepos.entrySet()`. Misleading, and a real startup-latency issue past a handful of namespaces.
2. **`GitHubWriteNotSupportedException` is also thrown from read-path/admin-listing methods in `GitHubUserAccessStore`** where the failure isn't "you tried to write" but "this operation has no meaning in GitHub mode". Message text is accurate at each site — cosmetic, not a correctness bug.

**Fix**: for 1, fix the javadoc or make `cloneAll()` genuinely parallel (reuse the `ManagedExecutor` `GitHubStartupInitializer` already has). For 2, rename to something more general (`GitHubOperationNotSupportedException`) or add a second exception type for the non-write cases.

(Surfaced during #3066's review.)

Inspect GitHubCloneManager.cloneAll() and its javadoc, then compare the sequential loop with the ManagedExecutor available through GitHubStartupInitializer. Review GitHubUserAccessStore and all GitHubWriteNotSupportedException call sites before choosing the documented or generalized behavior. Done means the documentation and exception naming accurately describe every affected operation, with existing behavior preserved unless parallel cloning is selected.

Written by the indexing model from the issue text.