ci: replace Dependabot with Renovate for dependency updates

[frankieyan]

Short description

This PR moves Reactist from Dependabot to Renovate for several reasons:

• We're using it across all (with some exceptions) other Doist-repos
• It isn't as flexible when it comes to constructing commit messages. For example, Renovate allows customizing the commit prefix based on the incoming package's version, so updating a major version of a core dependency can automatically be categorized as a breaking change.
• Dependabot was turned off automatically because we haven't done a good job staying on top of them

We also include config options that target the token package introduced in #1094, but it won't take effect until that is merged.

PR Checklist

• Added tests for bugs / new features
• Updated docs (storybooks, readme)
• Reviewed and approved Chromatic visual regression tests in CI

[doistbot]

This PR replaces Dependabot with Renovate and adds package rules mapping @doist/product-libraries-tokens updates to conventional-commit prefixes that align with the repo's semantic-release pipeline.

Few things worth tightening:

• Add "semanticCommits": "disabled" to the major-version package rule. Renovate auto-enables semantic commits (detected from the repo's conventional-commit history), which causes it to ignore commitMessagePrefix — so a major token bump won't actually get feat(deps)!: and semantic-release won't treat it as breaking. This is a per-rule override and won't affect the patch/minor rules that rely on semanticCommitType.

_{Share Feedback • Review Logs}

[doistbot]

commitMessagePrefix is ignored by Renovate when semanticCommits is enabled. Semantic commits are on here: the patch/minor rules depend on semanticCommitType (only honored with semantic commits enabled), and Renovate's default auto detection will enable them given Reactist's conventional-commit history, which the check-semantic-pull-request workflow enforces. So a major @doist/product-libraries-tokens bump won't actually get feat(deps)!: — Renovate builds the prefix from the base preset's semanticCommitType/semanticCommitScope (likely chore/deps) with no !, and semantic-release won't cut a breaking/major release, defeating the rule's stated purpose. Add "semanticCommits": "disabled" to this package rule so commitMessagePrefix takes effect; it's a per-rule override and won't affect the patch/minor rules, which keep using semanticCommitType.

[frankieyan]

@doistbot the docs is kind of ambiguous, because it says:

Prefix to add to start of commit messages and PR titles. Uses a semantic prefix if semanticCommits is enabled.

However, looking at the source, it looks like semanticCommits is guarded with a !upgrade.commitMessagePrefix check: https://github.com/renovatebot/renovate/blob/170b972320cd4a6de644992586f5156eb20d9de5/lib/workers/repository/updates/generate.ts#L69

So that seems to me that semanticCommits is filling in as the default value, and commitMessagePrefix is used to override it. I guess it doesn't hurt to disable it, but I don't think it's necessary either.

[doistbot]

You’re right—the Renovate source confirms that semanticCommits only supplies a prefix when upgrade.commitMessagePrefix is unset. For the major rule, commitMessagePrefix: "feat(deps)!:" therefore takes precedence and produces the intended breaking conventional-commit title. That’s also what the repository’s semantic PR check and semantic-release configuration consume.

"semanticCommits": "disabled" would be redundant rather than harmful. I’ll withdraw that concern; the configuration can remain as-is.

[doistbot]

This PR updates ci: replace Dependabot with Renovate for dependency updates. No issues were flagged in the reviewed diff.

_{Share Feedback • Review Logs}

[pawelgrimm]

🚀