build(release): verify reproducible release candidates

[LMLiam]

Outcome

Two isolated builds of one source revision produce byte-identical files for the complete staged Maven publication. A candidate manifest identifies every compared file and build input.

Artefact set

Use the publication contract from #413.

• For each of core, coroutines, minimessage, paper, serializer, test, and test-snapshot: main JAR, sources JAR, Dokka-backed Javadoc JAR, Project Object Model (POM), and Gradle Module Metadata.
• For bom: POM and Gradle Module Metadata only.

Include repository metadata and checksum files only when the publication task creates them as part of the consumer repository. Do not compare logs, test reports, Gradle caches, or temporary repository metadata.

Equivalence rule

Build twice from the same clean source revision in different temporary worktrees, processes, temporary Maven repositories, and empty task-specific Gradle user homes. Use the same pinned Java Development Kit, Gradle wrapper, Kotlin version, dependency locks, and verification metadata. Disable build-cache reuse and rerun publication tasks.

Every file in the artefact set must have the same relative repository path and identical bytes. Compare SHA-256 digests and file sizes. Do not normalise a timestamp, archive member, POM, or module file after publication to make it match.

Candidate manifest

Write build/reports/release-candidate/manifest.json and a concise Markdown summary. Record:

• schema version;
• repository and source commit;
• project version;
• operating system and architecture;
• Java vendor and version;
• Gradle and Kotlin versions;
• build command and verification mode;
• coordinate, classifier, extension, relative path, size, and SHA-256 for each file; and
• the comparison result for both isolated builds.

The report is a generated release candidate, not a checked source file. Fail before publication evidence when a file is missing, extra, renamed, or different.

Pull-request stack

1. Make each declared publication output reproducible.
2. Add the two-build comparison and candidate manifest.
3. Add deterministic fixtures for missing, extra, and changed files.

Dependencies

Blocked by #409, #411, and #413. This issue does not require a public release.

Acceptance criteria

• The comparison includes all publication files from build(publish): complete and consume the published module set #413 and no unrelated build output.
• Both builds use isolated worktrees, repositories, processes, and Gradle user homes.
• Every accepted file is byte-identical and has a recorded SHA-256 and size.
• The candidate manifest records the exact revision and toolchain.
• A missing, extra, renamed, or different file fails the candidate.
• No Source Bill of Materials (SBOM) or public attestation is produced in this slice.