chore(deps): restrict Node engine below 24.16.0 (#16222)

<!-- Template from
https://github.com/kubevirt/kubevirt/blob/main/.github/PULL_REQUEST_TEMPLATE.md?-->
<!--  Thanks for sending a pull request!  Here are some tips for you:
1. Consider creating this PR as draft:
https://github.com/CherryHQ/cherry-studio/blob/main/CONTRIBUTING.md
-->

> ### 🚨 Branch strategy — read before opening this PR
>
> The v2 refactor has merged into `main`, so **`main` is the default
branch for active development** (v1 and v2 code currently coexist there
— expect large, breaking changes).
>
> - **Active development** (features, refactors, optimizations, fixes
for the current codebase) → target **`main`** (the default base).
> - **v1 maintenance** (hotfixes and subsequent v1 releases) → branch
from and target **`v1`**, _not_ `main`.
>
> A v1 fix does **not** auto-carry to `main`: if the same bug exists on
`main`, open a separate forward-port PR targeting `main`. Before
touching subsystems being replaced, read `docs/references/data/` and
watch for `@deprecated` markers — they flag code being deleted.

### What this PR does

Before this PR:

Developers could install dependencies with Node.js 24.16.0 or newer even
though those versions can trigger incomplete Electron binary extraction
through the Electron installer dependency chain.

After this PR:

The project declares `>=24.11.1 <24.16.0` as the supported Node.js range
and enables `engine-strict=true` so pnpm fails early when the active
Node.js runtime is outside that range.

<!-- (optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)`
format, will close the issue(s) when PR gets merged)*: -->

Fixes #N/A

### Why we need it and why it was done in this way

The following tradeoffs were made:

This pins the supported Node.js 24 range below 24.16.0 instead of
changing Electron, `extract-zip`, or transitive dependency resolution.
That keeps the change small and focused on protecting local installs
until the upstream extractor issue is resolved in the Electron
dependency chain.

The following alternatives were considered:

- Overriding `yauzl` to a newer version was considered, but that changes
transitive dependency behavior and is broader than an engine guard.
- Manually extracting Electron with system `unzip` works as a local
workaround, but it is not suitable as a project setup requirement.
- Upgrading Electron may eventually be the right long-term fix, but this
PR only prevents known-bad Node runtimes from producing broken installs.

Links to places where the discussion took place: <!-- optional: slack,
other GH issue, mailinglist, ... -->

- https://github.com/electron/electron/issues/51619
-
https://community.getmailspring.com/t/building-is-broken-with-node-js-26-1-0-and-24-16-0/14475
- https://github.com/nodejs/node/issues/63487

### Breaking changes

<!-- optional -->

Developers using Node.js 24.16.0 or newer must switch to a supported
Node.js version before running pnpm install. This affects development
tooling only and does not change runtime behavior for app users.

### Special notes for your reviewer

This is a development environment guard for an upstream Node.js/Electron
installer incompatibility. It intentionally does not change application
code.

### Checklist

This checklist is not enforcing, but it's a reminder of items that could
be relevant to every PR.
Approvers are expected to review this list.

- [x] Branch: This PR targets the correct branch — `main` for active
development, `v1` for v1 maintenance fixes
- [x] PR: The PR description is expressive enough and will help future
contributors
- [x] Code: [Write code that humans can
understand](https://en.wikiquote.org/wiki/Martin_Fowler#code-for-humans)
and [Keep it simple](https://en.wikipedia.org/wiki/KISS_principle)
- [x] Refactor: You have [left the code cleaner than you found it (Boy
Scout
Rule)](https://learning.oreilly.com/library/view/97-things-every/9780596809515/ch08.html)
- [x] Upgrade: Impact of this change on upgrade flows was considered and
addressed if required
- [ ] Documentation: A [user-guide update](https://docs.cherry-ai.com)
was considered and is present (link) or not required. Check this only
when the PR introduces or changes a user-facing feature or behavior.
- [ ] Self-review: I have reviewed my own code (e.g., via
[`/gh-pr-review`](/.claude/skills/gh-pr-review/SKILL.md), `gh pr diff`,
or GitHub UI) before requesting review from others

### Release note

<!--  Write your release note:
1. Enter your extended release note in the below block. If the PR
requires additional action from users switching to the new release,
include the string "action required".
2. If no release note is required, just write "NONE".
3. Only include user-facing changes (new features, bug fixes visible to
users, UI changes, behavior changes). For CI, maintenance, internal
refactoring, build tooling, or other non-user-facing work, write "NONE".
-->

```release-note
NONE
```

.npmrc

@@ -0,0 +1 @@
+engine-strict=true

package.json

@@ -8,7 +8,7 @@
   "author": "support@cherry-ai.com",
   "homepage": "https://github.com/CherryHQ/cherry-studio",
   "engines": {
-    "node": ">=24.11.1"
+    "node": ">=24.11.1 <24.16.0"
   },
   "scripts": {
     "start": "electron-vite preview",