Harden Chromium fetch, CI, and release flow

[max4c]

Summary

• add the pinned CEF fetch script and move vendor paths under macos/vendor/cef
• update CI to cache and fetch CEF, regenerate the Xcode project, and build the Chromium macOS app target
• switch the release script and README guidance onto the Xcode/CEF app build while keeping SwiftPM as the WebKit fallback path

Testing

• swift build
• swift test
• bash scripts/smoke-cli.sh
• bash scripts/fetch-cef.sh
• cd macos && xcodegen generate
• xcodebuild -project /Users/maxforsey/Code/bugbook-chromium-stack/macos/Bugbook.xcodeproj -scheme BugbookApp -configuration Debug build

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ebc74775f4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Refresh CEF runtime unconditionally before release build

The release flow skips scripts/fetch-cef.sh whenever macos/vendor/cef/current/Release/Chromium Embedded Framework.framework already exists, but that only proves some runtime is present, not that it matches the pinned version or host architecture. If current points to an older pin (or to x64 artifacts from a prior Rosetta/x86 run), this script will silently build against stale/incompatible CEF and can fail link/run or ship the wrong runtime. Calling the fetch script every time (or validating current against expected platform/version) avoids that mismatch.

Useful? React with 👍 / 👎.