Fix publish idempotency after warehouse switches or empty remotes

[knifflig]

Problem

Publish idempotency currently short-circuits from local lock version records before checking the remote warehouse state. After switching to a fresh or empty warehouse, a version can be skipped locally even though nothing exists remotely.

This breaks the intended flow for warehouse changes and makes the local lock too authoritative.

Goal

Make publish idempotency remote-aware so a fresh warehouse can be bootstrapped correctly without manual lock destruction.

Required changes

• Check remote table existence and remote publish checkpoints before returning an idempotent skip.
• If the remote table is missing, treat the publish as a first publish for that warehouse binding.
• Keep refresh semantics unchanged.
• Preserve resume-from-checkpoint behavior when remote partial checkpoints exist.

Design notes

• Local version records can remain useful as cache or history, but they must not be the sole authority for skip decisions.
• Remote checkpoint properties such as dbport.upload.v2.<version>.completed should be the decisive source for remote idempotency.

Acceptance criteria

• Publishing to a new empty warehouse does not skip only because the local lock contains a completed version.
• Existing remote completed checkpoints still produce a safe no-op in default mode.
• Interrupted publishes still resume correctly.
• Tests cover warehouse switch and empty-warehouse bootstrapping scenarios.