fix(publish): return deterministic conflict on concurrent coordinate race

[FenjuFu]

What

Closes #617.

Concurrent publishes for the same final (namespace_id, slug, owner_id) / (skill_id, version) coordinate could both pass the check-then-create reads and then race on the database unique constraints. The losing request surfaced an unhandled DataIntegrityViolationException as HTTP 500.

Fix

Follow the codebase's existing concurrency idiom — LabelDefinitionService, ReviewService, and PromotionService all catch (DataIntegrityViolationException) and translate the unique-constraint violation into a deterministic business error. SkillPublishService.publishFromEntries now does the same at its two check-then-create insert points:

• Skill insert — skill(namespace_id, slug, owner_id) unique constraint
• SkillVersion insert — skill_version(skill_id, version) unique constraint

Both translate a violation into a deterministic DomainBadRequestException("error.skill.publish.concurrentConflict") (HTTP 4xx) instead of a 500. No same-transaction re-read is attempted (that would hit the aborted-transaction trap); the losing publish rolls back cleanly and returns a retryable conflict, matching the issue's "one success and one deterministic business conflict" contract. No response-shape change.

i18n

New key error.skill.publish.concurrentConflict added to messages.properties (en) and messages_zh.properties (zh); other locales fall back to the default bundle.

Tests

Two unit tests in SkillPublishServiceTest assert that a DataIntegrityViolationException from the skill insert and from the version insert each surface as error.skill.publish.concurrentConflict rather than propagating as a 500, and that no version save / object upload happens once the coordinate race is lost.

Scope

This eliminates the reported 500 — the core of "they should not produce an internal server error". The issue also raises a broader follow-up: deterministic serialization of interleaved publish/review lifecycle mutations (pending-review withdrawal vs latest_version_id). That is a larger lifecycle change; happy to address it in a separate PR if maintainers want it in scope here.