chore: release v0.8.10

[miguel-heygen]

Stable release. Merging this PR publishes — the workflow checks out the merge SHA, creates the v0.8.10 tag there, publishes the npm packages, and cuts the GitHub release using releases/v0.8.10.md as its body.

I stopped at opening the PR deliberately: the publish is the irreversible step and the process puts it behind a human merge. The local tag was not pushed.

What ships

One commit since v0.8.9:

• Studio: name the cause when a render request fails (#3424)

Studio's render POST caught its error without binding it, so every transport failure — a dead server, a DNS error, an aborted request, a server that died mid-render — surfaced as one sentence. That string also travels into the feedback report, so failures that reproduce every time still arrived with nothing to act on. The cause is now named alongside the existing CLI guidance.

That is the whole release. It is small on purpose: the observability is worth shipping ahead of the other fixes in flight.

One thing to know before merging

The pre-commit largefiles hook refused this commit:

ERROR: large binaries are being committed to git instead of LFS.
       (limit: 500 KB - override per-commit with HF_MAX_NONLFS_KB)
  - docs/changelog.mdx (503 KB)

I used the hook's own documented escape (HF_MAX_NONLFS_KB=1024), not --no-verify, so the
check still ran and still reported. Why that is the right call rather than a bypass:

The file is fine. 514 KB across 5237 lines is 170 release entries at ~3 KB each. No
embedded blob, longest line 717 characters. It is exactly what 170 releases of notes weigh.

The check misclassifies it. scripts/check-large-files.sh exists to catch binaries
committed straight into the pack instead of LFS - that is its comment, its error message and
its name. But it has no binary detection: it exempts symlinks, registry/* and LFS-tracked
paths, then judges everything else on wc -c alone. A line-diffable markdown source trips a
binary guard that never checks for binaries.

Its suggested fix would be wrong here. The error tells you to add an LFS pattern. A
changelog is text that belongs in git history and diffs line-by-line; routing it through LFS
to satisfy a binary rule would be the wrong trade.

So the fix belongs in the check (exempt text, or at least .md/.mdx), not in the
changelog. Until then every release trips it, because the file only grows. Splitting the
changelog may still be worth doing for docs rendering - 170 entries on one page is a lot -
but that is a separate argument from this hook.

Not in this release

• #3425 (unwritable font cache aborting a render) was still in CI when this was cut.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
hyperframes	🟢 Ready	View Preview	Aug 22, 2026, 3:12 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.