chore: Format changelogs with Oxfmt

[Mrtenz]

Explanation

This updates changelog validation to use Oxfmt instead of Prettier.

References

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

---

Note

Low Risk
Primarily build/lint tooling and dependency bumps; no runtime/controller logic changes, with only minor risk of CI/release automation differences due to formatter changes.

Overview
Updates changelog automation to use Oxfmt instead of Prettier by passing --formatter oxfmt in scripts/update-changelog.sh and scripts/validate-changelog.sh, and by wiring create-release-branch to use the same formatter.

Bumps @metamask/auto-changelog to ^6.1.0 across packages (and updates @metamask/create-release-branch), removes changelog-specific lint steps from some packages, and tweaks .oxfmtrc.json/lint:misc so Oxfmt is the primary formatter and changelogs are no longer specially ignored.

^{Reviewed by Cursor Bugbot for commit da6cf29. Bugbot is set up for automated code reviews on this repo. Configure here.}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​metamask/​auto-changelog@​6.0.0 ⏵ 6.1.0			+1	+2
	@​metamask/​create-release-branch@​4.1.4 ⏵ 4.2.0	+21		+1	+10

View full report

[Mrtenz]

This overrides the binary create-release-branch when running yarn create-release-branch, but Yarn is still able to resolve the actual binary in the script. It's a bit hacky though, so we may also want to consider creating a script with a different name (yarn create-release?).

[mcmire]

Hmm... good point.

I'd hate to have two different commands to do the same thing. I feel like that would be confusing. Maybe we should give create-release-branch the ability to read from a createReleaseBranch property in package.json, and we can set formatter there instead of using a command-line option?

[Mrtenz]

Was thinking about having a config option as well. We already have release.config.json, so maybe it makes sense to add the option there, and have auto-changelog and create-release-branch read from that?

Do you think we should do that before merging this?

[mcmire]

True, we do have that config file. It's currently used by action-publish-release, but we could certainly reuse it for this purpose.

Do you think we should do that before merging this?

I was thinking we would at first, but perhaps we don't have to. I guess hardly anyone uses yarn exec create-release-branch to run this tool; it's more likely they use yarn create-release-branch (and I believe this is what we advise in the release instructions anyway). So maybe it would only be confusing for us.

I do think it would be a good idea for create-release-branch to read formatter from a config file so we wouldn't need this line, but maybe having a "hack" for now isn't so bad.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b9e7abd. Configure here.}

[mcmire]

LGTM.