[P0][Publishing] Implement idempotent immediate and scheduled publication jobs

[Ankit6149]

Parent epics

#63, #57, #66

User problem

Publishing must not depend on a browser request that can time out or be retried into duplicate posts. Immediate and future scheduled publication need durable jobs, explicit confirmation, verified account context, timezone semantics, and truthful unknown/failure states.

Scope

• Canonical Publication command/record with workspace, campaign, destination, current draft revision, connection/target identity, mode, scheduled time/timezone, idempotency key, approval/source/quality snapshot, and status.
• Server-side preflight for permissions, current source, current revision, approval policy, connector capability, length/required fields, quota, and schedule validity.
• Durable immediate/scheduled job through [P0][Cloud] Add a durable background job system for ingestion, generation, export, and publishing #73.
• Statuses: awaiting confirmation, scheduled, queued, publishing, published, failed, rejected, unknown, cancelled, and superseded.
• Provider response reference/permalink where available and safe error/retry policy.
• Cancel/reschedule before execution and clear rules after publishing begins.
• Manual/export routes remain separate and must never be recorded as direct publication.

Idempotency and truth rules

• Retrying the same publication ID cannot create a second post.
• Unknown provider outcome remains unknown until reconciled; do not report failed or published without evidence.
• Draft edits after scheduling either create a new explicit scheduled revision or leave the original immutable; no silent content replacement.
• Connection revocation, permission change, stale source, or invalidated approval blocks execution.

Acceptance criteria

• Confirmation identifies platform, account/page/community, exact revision, and time/timezone.
• Duplicate API/job delivery creates at most one external publication.
• Scheduled publication survives browser closure, deploy, and worker restart.
• Cancel/reschedule is race-safe and auditable.
• Published state requires connector confirmation and stores a stable reference when available.
• Unknown/failure states provide safe reconciliation/retry guidance.
• Credential-backed tests exist for every connector advertised as verified.

Tests

Duplicate requests, worker crash, timeout after provider accepted, expired token, revoked scope, stale/edited draft, timezone/DST, cancel race, reschedule, provider rate limit, unknown result reconciliation, and cross-tenant tampering.