feat(branding): ship as Basilica Audio, and put the changelog on the release page

[yves-vogl]

Implements the two suite-level issues in this repository:
basilica-audio/.github#2 (vendor identity) and
basilica-audio/.github#3 (release notes).
Identical in shape across all thirteen plugins. The suite-level decision is
ADR 0001.

1. Vendor identity

Identifier	Before	After	Why
COMPANY_NAME	Yves Vogl	Basilica Audio	The string a host groups by. Display only.
BUNDLE_ID	com.yvesvogl.triptych	unchanged, on purpose	How a host recognises the plugin across sessions, and the preset JSON plugin field. Changing it breaks existing projects for no visible benefit.
COMPANY_COPYRIGHT	Copyright (c) 2026 Yves Vogl	unchanged, on purpose	A trading name is not a copyright holder.
PresetManagerConfig::manufacturerName	Yves Vogl	Basilica Audio, with a migration	See below.

Both frozen identifiers carry a comment at their definition explaining that they are decisions, not leftovers, so nobody later "finishes the rename".

The identity keys did not move, and that was checked rather than assumed

Apotheosis was built Release before and after the change and the AU Info.plist plus the VST3 moduleinfo.json diffed. Everything that establishes identity is byte-identical; only display strings moved:

  AU  AudioComponents[0]
      "type":                    "aufx"                        unchanged
      "subtype":                 "Apth"                        unchanged
      "manufacturer":            "Yvsv"                        unchanged
      CFBundleIdentifier:        "com.yvesvogl.apotheosis"     unchanged
      NSHumanReadableCopyright:  "Copyright (c) 2026 Yves Vogl" unchanged
-     "name":                    "Yves Vogl: Apotheosis"
+     "name":                    "Basilica Audio: Apotheosis"

  VST3 moduleinfo.json
      Classes[0].CID  "ABCDEF019182FAEB5976737641707468"        unchanged
      Classes[1].CID  "ABCDEF011234ABCD5976737641707468"        unchanged
-     Factory Info.Vendor / Classes[*].Vendor  "Yves Vogl"
+     Factory Info.Vendor / Classes[*].Vendor  "Basilica Audio"

Four changed lines, all of them display strings. The tail of both CIDs, 5976737641707468, is Yvsv + Apth in hex - the manufacturer and plugin codes, neither of which this change touches (JUCE 8.0.14, juce_VST3ModuleInfo.h, VST3Interface::jucePluginId). That is the mechanism the safety claim rests on, confirmed on a real artefact rather than taken on trust.

Preset migration: adopt on first run, copy, never destroy

Chosen over "search both paths on load", and for maintenance risk rather than taste. Most of PresetManager's call sites through the preset directory write as well as read - rename, delete, save-over, set-default, bank export. Dual-path lookup would leave every one of them with a permanent two-directory question (does a rename move a legacy file? does a delete reach into the old folder?) for a directory that is empty on most machines. A one-shot adoption in the constructor keeps exactly one authoritative directory and confines the whole rename to eight lines.

Properties that matter to a user:

• Copies, never moves. An older build of Triptych - or a downgrade after this release - still finds its presets exactly where it left them. A move-based migration would have made downgrading lossy.
• Never overwrites. A file already present under the new name always wins, so a preset saved after the update is never clobbered by an older namesake.
• Never deletes. The old folder is left alone. Removing a user's files to tidy up a folder name is not a trade worth making; docs/branding.md tells them where it is if they want it gone.
• Idempotent and nearly free. One isDirectory() call on a machine that never had the old folder.
• Cannot escape into the real preset folder during tests. getLegacyUserPresetsDirectory() returns nothing when the current directory is overridden for a test without a matching legacy override - otherwise a test would read, and copy from, the presets of whoever is running it.

Five new cases in tests/PresetManagerTests.cpp pin all of it, including the folder shapes on both platforms - asserted on whichever CI runner is executing, so macOS and Windows each check their own rather than one machine checking both on paper.

2. Release notes

release.yml now calls the shared basilica-audio/.github/release-notes composite action twice: once in create-release, publishing this repository's CHANGELOG.md section for the tag plus the suite-wide footer, and once in a new publish-release-notes job after the platform builds, rewriting the body with a Downloads table built from the assets that were actually attached.

The footer answers the three questions the Releases page never did: what is in each archive, whether it will open, and where it goes. The signing status is stated in both directions - macOS Developer ID signed, notarised and stapled, with the two commands to verify it; Windows not Authenticode-signed, so SmartScreen will warn, and here is what to click. It lives in one repository, so a wording fix does not need thirteen pull requests.

A tag whose version has no ## [x.y.z] section in CHANGELOG.md now fails the release job, in create-release, before anything is built or uploaded. Deliberate: publishing an empty release page is the problem being fixed, and failing there costs a changelog edit and a re-tag rather than a cleanup of a half-published release.

Verification

• ctest green locally on Apotheosis, the plugin built for this change: 169/169, up from 164, the five new cases being the migration contract.
• A release workflow only fully proves itself on a tag, and no tag was cut for this - so nothing here claims a green release run. What was actually exercised:
  • the action's body generation against real changelogs with the gh CLI stubbed: zip-only and zip + .pkg + .sha256 asset shapes, the no-assets pass, the missing-section failure, and its escape hatch;
  • a real GitHub Actions run from a throwaway branch calling the action with dry-run - run 33088601424, green - which proves what local testing cannot: that an action hosted in a repository named .github resolves at all, and that the live asset list comes back as expected.
• Still unproven until the next real tag anywhere in the suite: the gh release create / gh release edit calls themselves, and the two-pass ordering inside a live release.yml. The first tag exercises both.