Cold-start content discovery: CreatorProfile carries featuredContentIDs but no tickets, so a new consumer can't hydrate the catalog

## Background

The consumer catalog (`CreatorContentView` in arkavo-org/app) is the primary discovery path for TDF-protected content: it lists a creator's published content as `ContentDescriptor` cards, then fetches the selected item's payload over Iroh and gates playback on KAS rewrap (Patreon entitlements).

The catalog is hydrated from `ContentTicketCache.shared.tickets(for: creatorPublicID)` — which only **filters the local, per-device cache** (`Sources/ArkavoSocial/ContentTicketCache.swift:88-90`). The cache is populated by prior fetches or manual ticket paste.

## The gap

A cold-start consumer (new device / never received a ticket) who resolves a creator's `CreatorProfile` cannot build the catalog:

- `CreatorProfile.featuredContentIDs: [Data]` carries **content IDs only** (`Sources/ArkavoSocial/CreatorProfile.swift:34`).
- `IrohContentService` has no ID→ticket resolution; `fetchContent(ticket:)` requires a full Iroh blob ticket.
- Result: the profile renders, the catalog is empty, and the only path in is out-of-band ticket sharing ("Paste content ticket"). That contradicts the catalog being the primary discovery method.

## Options

**A. Embed the catalog in the profile.** Add `contentCatalog: [ContentTicket]?` to `CreatorProfile` (`ContentTicket` is already `Codable`/`Hashable` in the same module). Creator app appends/replaces entries on each publish; consumer seeds `ContentTicketCache` from the fetched profile and renders descriptors as today.
- Pros: one fetch, no new service surface, `ContentTicket` already carries `contentID`/`version`/`creatorPublicID` for cache keys and conflict resolution.
- Cons: profile blob grows with catalog size; every content publish forces a profile re-publish.

**B. Separate catalog document.** Publish a `ContentCatalog` blob to Iroh; profile gains a single `catalogTicket: String?`. Consumer chases profile → catalog → descriptors.
- Pros: profile stays small; catalog can page/version independently.
- Cons: extra round-trip, a second document lifecycle to manage, more new API.

**Recommendation: A**, unless catalogs are expected to grow past a few hundred entries — descriptors are lightweight metadata, profiles are already re-published on edit, and A is adoptable incrementally.

## Backward compatibility

`CreatorProfile` uses synthesized `Codable` with plain `JSONEncoder`/`JSONDecoder` (`toData()`/`fromData()`). The new field must be **optional** (`[ContentTicket]?`) so already-published profiles (missing key → nil) keep decoding. Bump the doc-comment guidance on `version` accordingly.

## Adoption (follow-ups, separate repos)

1. **ArkavoKit**: model field + a `ContentTicketCache.seed(from: CreatorProfile)` helper + tests.
2. **Creator** (arkavo-org/Creator): on "Publish to Iroh", append the resulting `ContentTicket` to the profile's catalog and re-publish the profile (likely with a creator-facing toggle for which items are listed — not every published item should necessarily be public catalog).
3. **app** (consumer): after `fetchProfile`, seed the cache from `contentCatalog` before `loadContent`, removing the cold-start dependence on manual paste.

## Security note

Catalog entries are descriptors (title, manifest-lite, payload ticket) — deliberately public metadata. Access remains gated at KAS rewrap by the `patreon.arkavo.com` policy; listing gated content publicly is the intended storefront model. Creators just need control over *which* items are listed (step 2).

Start with Sources/ArkavoSocial/CreatorProfile.swift, ContentTicketCache.swift, and the IrohContentService references described in the issue. Review existing ContentTicket Codable behavior and profile decoding, then add tests covering an optional catalog and cache seeding, including profiles without the new key. Done means ArkavoKit exposes the catalog model and seeding behavior while preserving decoding of existing profiles.

Written by the indexing model from the issue text.