swamp issue: choose the target collective and control issue visibility -- at filing time and afterward -- from the CLI (with a settable default)

Problem

swamp issue {bug,feature,security} routes a new Lab issue to a collective server-side, from the author's default. When that default collective is private, the issue is filed private -- even when it is a broadly useful report (e.g. a core bug or feature request) that the author would rather file public, or file under a different collective. The CLI offers no way to pick the collective or set visibility at creation; the author only finds out afterward. And there is no CLI path to change an issue's visibility or collective after filing either -- today that requires the web UI (e.g. a report that should have been public had to be flipped to public by hand after filing).

Today the only creation-time routing control is --source swamp|platform (src/cli/commands/issue_submit.ts resolveIssueSource) and -x/--extension (routes a report at an extension's repo). Neither selects a collective nor sets visibility.

Ask (two parts, same code path)

A. Select the target collective, with a settable default

• Add --collective <slug> to the issue-filing commands (issue_bug / issue_feature / issue_security), threaded through submitIssue so the Lab filing names the collective instead of relying on the server's default. There is already an exact precedent for this flag shape: swamp subscription start --collective <slug> (src/cli/commands/subscription_start.ts: "Open this collective's billing page instead of your own").
• Make the default settable, so the common case needs no flag. Resolution order: --collective > env var (e.g. SWAMP_ISSUE_COLLECTIVE) > swamp config key (e.g. issue.collective) > the current server default. Env/config defaults are idiomatic in swamp already (SWAMP_DATASTORE, SERVE_LINKS_COLLECTIVES, trustedCollectives, the swamp config store).

B. Set issue visibility at creation

• Add a visibility flag -- --private <true|false> (or a --public toggle) -- on issue creation, so a report can be filed public (or explicitly private) rather than inheriting the collective's default, when the target collective supports public issues. Thread it into the submitIssue payload alongside the collective.
• If the chosen collective cannot host a public issue, refuse with a clear message rather than silently filing it private. (Visibility is already a first-class concept on the issue side: issue_edit.ts notes that escalating an issue's type to security "restricts visibility and cannot be reversed by non-admins", and #4510 concerns private-collective disclosure -- so the model already distinguishes private vs public.)

C. Change an existing issue's collective/visibility from the CLI

Setting at creation (A/B) does not help issues already filed, and the author cannot always predict the right collective/visibility up front. Add a CLI path to change them afterward, so no web-UI round trip is needed:

• Extend swamp issue edit <number> with --collective <slug> and the same visibility flag (--private <true|false> / --public). issue_edit already changes title/body/type, and type-escalation to security already changes visibility (src/cli/commands/issue_edit.ts), so visibility/collective are a natural fit there. (Alternatively a dedicated swamp issue move <number> --collective <slug> subcommand.)
• Honor the same "only if the target collective supports public issues" and the move hazards in #4510 (e.g. do not leak the source collective).

This is the direct issue-domain analog of #4170 (a CLI command to change an existing extension's visibility private -> public).

Grounding: what is CLI-side vs server-side

CLI-side (this request can specify precisely):

• New options on issue_bug / issue_feature / issue_security (src/cli/commands/issue_*.ts).
• Plumbing through resolveIssueSource / submitIssue (src/cli/commands/issue_submit.ts) and the filing-source model (src/domain/issues/issue_source.ts).
• For change-after (C): extend swamp issue edit (src/cli/commands/issue_edit.ts, already editing title/body/type) with --collective + the visibility flag, or add a swamp issue move subcommand.
• Default resolution via env var + swamp config (existing mechanisms).

Server-side (cannot be verified from the client source; maintainers to confirm feasibility):

• Whether the Lab API accepts a target-collective and/or a visibility parameter on issue creation.
• Whether a given collective supports public issues at all (plan/permission dependent). Part B is explicitly conditioned on "if the collective supports it".

Nice-to-have (small, related)

swamp issue get --json does not currently surface the issue's collective or visibility (verified: the JSON has no such key). Adding them would let an author confirm where/how an issue landed -- useful whether or not A/B are implemented.

Related

• #4239 -- file bugs/features/security against the platform source (the existing --source routing dimension; collective selection is orthogonal to it).
• #4510 -- a public activity log discloses the name of the private collective an issue was moved from (shows collective/visibility/move semantics already exist, and why choosing at creation beats moving after).
• #4170 -- CLI to change an existing extension's visibility (private -> public): the same create/change-visibility need, in the extension domain.