#1663 swamp CLI: surface the audience and resolvedInVersion fields swamp-club now serves

Problem

Two Lab API fields shipped from swamp-club that the swamp CLI cannot surface, because SwampClubClient.fetchIssue maps the server response into a narrow FetchIssueResponse and drops every field it does not name. So the data is served correctly and the people who asked for it still see nothing.

Both were delivered as the swamp-club half of their issues, with the CLI half deliberately deferred:

• audience (from #1216) — the effective audience of an issue plus every restriction that applies, now on GET /api/v1/lab/issues/<n> and on the create 201. #1216's reporter (mgreten) works through swamp issue, and his original complaint was precisely that creation and issue get "do not show an owning collective, visibility, or effective audience". Serving it does not fix that until the CLI renders it.
• resolvedInVersion (from #1112) — the swamp version that carried a fix, plus a shippedSince filter on the list endpoint. #1112's reporter is an agent that wants swamp issue get --json to carry the field so it can compare against swamp --version.

What is needed, per field

resolvedInVersion is a three-file change:

1. src/infrastructure/http/swamp_club_client.ts — add the field to FetchIssueResponse and to the fetchIssue mapper.
2. src/libswamp/issues/get.ts — add it to IssueGetData.
3. Optionally the human renderer in src/presentation/renderers/issue_get.ts; --json needs no change once IssueGetData carries it, since JsonIssueGetRenderer prints that verbatim.

audience is the same shape, plus deciding how to render a structured value in the human output (it is an object with a visibility and a reasons array, not a string).

#1112 also asked for swamp issue shipped [--since <version>]. The server side exists: GET /api/v1/lab/issues?shippedSince=<iso-or-version> composes with the visibility filter. A CLI subcommand would need src/cli/commands/issue_shipped.ts, a libswamp module, a SwampClubClient.shippedIssues(), and a renderer.

Notes

Version comparison is CalVer (YYYYMMDD.HHMMSS.0-sha.HASH), not semver, and the CLI has no semver comparison anywhere — its update check is string equality against a redirect target. The server parses the leading YYYYMMDD as a day, so --since is time-based rather than release membership; two issues shipped minutes apart can land in different releases. Worth stating in the CLI help rather than implying release semantics.

Filed as the tracking half of #1216 and #1112 so neither is closed as fully delivered while its consumer still sees nothing.