#664 Support epoch seconds as the version suffix to avoid push collisions

Problem

The current extension version format YYYY.MM.DD.N requires manually incrementing the last segment on each push. When iterating rapidly on an extension within a single day, this leads to frequent collisions — swamp extension push rejects the version because N was already published, requiring a manual bump and retry. This friction adds up during active development.

Proposed solution

Allow epoch seconds (Unix timestamp) as the last version segment, e.g. 2026.06.17.1750146900. This would:

• Eliminate push collisions entirely — each push gets a unique, monotonically increasing suffix
• Add diagnostic value — the version encodes the exact publish time, useful for correlating deploys with telemetry or incident timelines
• Remain lexicographically sortable within the same date prefix

The date prefix (YYYY.MM.DD) stays human-readable for at-a-glance identification; the epoch suffix handles uniqueness and precision.

Alternatives considered

• Sequential N with auto-increment on the server: Would solve collisions but doesn't add the timestamp diagnostic value. Also requires a server round-trip to determine the next N.
• Full epoch-only version (no date prefix): Loses the human-readable date at a glance.
• UUID suffix: Unique but not sortable or meaningful.

Scope

This could be a CLI-side convenience (e.g. --version-suffix epoch or a manifest config) that stamps the version before push, or a registry-side feature that accepts epoch suffixes in the version field. Either approach works — the key constraint is that the registry must accept version strings with large numeric suffixes.