Make publish job handling retry-safe

[thomashoneyman]

I spent some time thinking about #741, and I think we're still missing a couple things that will make the GitHub action reliable. Namely, this PR:

• makes duplicate publish submission atomic and status-aware;
• allows retries after terminal publish failures;
• exposes machine-readable submission, completion, and failure outcomes;
• treats equivalent already-published versions as idempotent success;
• validates fetched manifest identity before authoritative writes.

This PR is limited to the registry server, API, schema, and tests. It does not implement the GitHub Action or any Spago changes; I have some ideas about how we might want to build that, but I don't think it should live in this repo, and it should probably be built on purescript-github-actions-toolkit.

Publish duplicate detection and insertion now happen in one SQLite IMMEDIATE transaction. Acquiring the write lock before the lookup prevents concurrent requests from both observing no existing job and inserting separate jobs.

For the same package name and version:

• an unfinished job is returned as duplicate-active;
• an exact-payload successful job is returned as already-published;
• a terminal failed job does not block a new attempt;
• a successful unpublish invalidates prior successful-publish reuse.

Publish submission responses contain jobId and a disposition, which is one of:

1. created
2. duplicate-active
3. already-published

Completed publish jobs expose a successful terminal disposition of published or already-published. Failed jobs expose a structured error with a job-failed or job-timeout code and a message.

I made some efforts to preserve compatibility (API compatibility, not library compatibility) with older clietns:

• jobId and HTTP 200/201 behavior remain unchanged.
• The new JSON fields are optional in the codecs.
• Historical responses and database rows remain decodable.
• Existing clients decoding JobCreatedResponse accept publish responses containing the new field.
• A codec regression test covers old responses with new clients and new responses with the existing response codec.

The intentional behavior change is that an equivalent already-published request succeeds with a machine-readable disposition instead of terminating as a failed job with free-text log output.