#3440 whoami reports each collective's private source hosting and namespace privacy, so the CLI quality rubric can match the registry's repository-verified verdict

Problem

Since #3396 the registry awards repository-verified to a private extension whose collective has private source hosting (lib/domain/scorecard/score.ts repositoryVerifiedFactor: privateSourceHosting && isPrivate). The CLI's local rubric (swamp extension quality) has to reach the same verdict as the registry, so private-source collectives can pass a full-score CI gate without the CLI ever claiming points the registry will not award. That is the CLI side of #3406.

The CLI cannot see either input today:

• Private source hosting: stored only on the collective profile. GET /api/whoami does not return it: organizations carries slug, name, role and personal; collectiveEntitlements carries plan, billing and trial. The extension score and metadata endpoints read it internally but return only the composed score, and only for an extension that already exists.
• Namespace privacy: on a first publish lib/app/confirm-push.ts makes the extension private when the manifest asks for private OR isNamespacePrivate(namespace) is true, whatever the manifest says otherwise. whoami does not say whether a collective's namespace is private, so the CLI cannot predict the visibility of a new extension. (For an existing extension the CLI already reads isPrivate through the extension visibility endpoint.)

Proposed solution

Add both facts to GET /api/whoami as a new optional top-level field joined on slug, for example:

collectiveSourceHosting: [
  { slug: "acme", privateSourceHosting: true, privateNamespace: true }
]

• A separate top-level field, not extra keys on organizations entries: the CLI treats organizations as an authorization contract for extension push and pull (see AGENTS.md in the swamp repo), the same reason collectiveEntitlements is separate.
• Optional, so older or self-hosted servers that omit it keep working; the CLI falls back to its current behaviour when it is absent.
• Readable by any member of the collective (it is not billing data), and present for collective tokens as well as user sessions, since CI gates run with collective tokens.

Acceptance

• whoami returns the field for every collective the caller belongs to, with privateSourceHosting matching the admin toggle and privateNamespace matching what isNamespacePrivate would return for that collective's namespace.
• Toggling private source hosting in /admin/collectives is reflected in the next whoami response.
• Collective-token whoami responses include the field for that collective.

Context

• Server change that introduced the rule: #3396 (swamp-club PR #1337).
• CLI work that consumes this: #3406 (blocked on this issue).