Channels: Channel snapshots

User story

We need each ChannelRequest to link to an immutable snapshot of the channel's configuration at the time the request was made, so that historical requests always show the config that was active when they happened.

Details

Implement ChannelSnapshot.get_or_create_current/1 following the existing Workflow Snapshots pattern. A new snapshot is only created when the channel config changes (triggered by a lock_version bump). Many requests reference the same snapshot.

Implementation notes

Dependencies: #4399 (schema), #4405 (observer creates requests that reference snapshots)

Key technical considerations:

• Race condition on concurrent requests after config change: use ON CONFLICT DO NOTHING + re-read pattern to avoid crashing on the unique index [:channel_id, :lock_version]
• Snapshot denormalises credential names from ProjectCredential → Credential so they survive credential renames/deletions
• Snapshots are immutable after creation (timestamps(updated_at: false))

Release notes

N/A — internal data integrity mechanism, not directly user-facing.

User acceptance criteria

• get_or_create_current/1 returns existing snapshot if one exists for the channel's current lock_version, or creates a new one
• Race condition handled: concurrent requests after config change don't crash on unique index violation (ON CONFLICT DO NOTHING + re-read)
• Snapshot captures: name, sink_url, credential IDs + denormalised credential names, enabled, lock_version
• New snapshot created when channel config changes (triggered by lock_version bump)
• ChannelRequest records reference channel_snapshot_id
• Snapshots are immutable after creation

Start with the existing Workflow Snapshots pattern and the schema work in #4399, then inspect how the observer from #4405 creates ChannelRequest records. Done means current-version snapshots are reused or safely created under concurrency, capture the listed channel and credential data immutably, and are referenced by ChannelRequest records.