build(config): fix ShipIt pre-release handling, revise merge strategy

[7sharp9]

Overview

Three fixes discovered while verifying EasyBuild.ShipIt (adopted in #443) actually
works against this repo's current state, we want to address this befor CI wiring:

1. Add pre_release: alpha to CHANGELOG.md's front matter. Without it, the next
   qualifying commit would silently drop the -alpha suffix and promote GenPRES to
   a "stable" release as a side effect, we don't want this to happen intended until the
   MVP work (auth, etc.) is done.
2. Rename the latest changelog heading from [0.1.2-alpha] to [0.1.2-alpha.1].
   ShipIt's pre-release increment logic only knows how to bump an already-numbered
   tag (alpha.N -> alpha.N+1); a bare alpha tag has no number for it to find,
   and it hits an unhandled branch in its own source and crashes.
3. Revise ADR-0021 and the implementation plan: There were concerns around
   squash-only merging (loses commit-level history). ShipIt's own README treats squash and
   rebase merging as equally valid, so the decision is now just disabling GitHub's
   merge-commit option while leaving both squash and rebase enabled, rather than
   forcing squash on everyone.

Refs #234

[greptile-apps]

Greptile Summary

This PR preserves GenPRES’s alpha prerelease sequence and revises the proposed GitHub merge strategy to permit squash or rebase merges while disabling merge commits.

• Adds the ShipIt pre_release: alpha setting and numbers the existing alpha release.
• Updates ADR-0021, its implementation plan, and the design-history index for the revised merge strategy.
• Leaves one rollout instruction inconsistent with the repository’s documented ShipIt command.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking rollout-documentation inconsistency around the ShipIt merge-commit option.

The prerelease and ADR changes are coherent, but the implementation plan relies on --skip-merge-commit being present even though the repository’s documented ShipIt command omits it.

Files Needing Attention: docs/implementation-plans/234-improve-build-system.md

Important Files Changed

Filename	Overview
CHANGELOG.md	Adds explicit alpha prerelease configuration and changes the latest historical release heading to the numbered prerelease expected by the proposed tooling.
docs/implementation-plans/234-improve-build-system.md	Revises the merge-settings rollout but incorrectly claims all existing ShipIt invocations already include the merge-commit skip option.
docs/mdr/design-history/0000-change-log.md	Updates the ADR index to summarize the revised merge strategy consistently.
docs/mdr/design-history/0021-build-system-versioning-and-release.md	Revises the proposed decision and trade-offs to disable merge commits while retaining squash and rebase workflows.

_{Reviews (1): Last reviewed commit: "docs(config): revise ADR-0021 merge stra..." | Re-trigger Greptile}

[7sharp9]

@ploeh Based on your feedback, we can do either rebase or squash PR's. The only thing to remember is that at PR time (Assuming this is turned on at the CI level), if you use rebase PR, then each commit in the PR would become a bullet point in the changelog, whereas a squash PR merge would be a single entry, albeit probably a fat one.

[7sharp9]

@halcwb I think the SDK moved from 10.0.302 to 10.0.400, and that might be the cause of the failing test, nothing else pertinent seems to have changed.

[ploeh]

@ploeh Based on your feedback, we can do either rebase or squash PR's. The only thing to remember is that at PR time (Assuming this is turned on at the CI level), if you use rebase PR, then each commit in the PR would become a bullet point in the changelog, whereas a squash PR merge would be a single entry, albeit probably a fat one.

Uh, I really prefer merges (keeping history intact and all that), so if the choice is between squash or rebase, then pick the one you prefer 😀