Release-prep: v0.8.5 (VERSION bump + release notes)

[vybe]

Prep for the v0.8.5 cut (dev → main follows once this lands):

• VERSION 0.8.0 → 0.8.5 (read by /api/version, mounted into the backend image, base-image tag)
• docs/releases/0.8.5.md: full grouped issue lists (78 public + private-tracker features/fixes) folded into the pre-cut seed — upgrade notes (ent#187 skill packages, base-image rebuild, ent#125 deploy default) and Known-limitations block preserved verbatim

No code changes. Follows the v0.8.0 pattern (#1528).

🤖 Generated with Claude Code

[AndriiPasternak31]

/validate-pr — APPROVE (pending the pytest matrix going green; content validation complete).

Not stale — the #1778 fold is genuine

The obvious risk on a release-notes PR authored after #1778 landed is silently reverting it. It doesn't:

• Branch point is 7041af23 — the current dev tip, containing both #1778 and #1765.
• Diffing dev's 0.8.5.md against this one, the only removed lines are **Released**: _pending cut_ and the 3-line PRE-CUT SEED marker — the marker whose own text said "fold this section in rather than overwriting it." Removing it is the correct outcome of folding.
• All five #1778 landmarks present: base-image-rebuild note, ent#125 deploy-default flip, Known-limitations block, the #1741 not-fixed line, the unentitled-MCP-tools line.
• Section fold is clean: 5 generated sections added (Highlights/Features/Fixes/Refactors/Documentation), all 4 inherited sections preserved in place.

Issue lists check out

Rather than trust the lists, I traced them:

• 78 public issues listed — matches the header's "78 public" exactly.
• 75 trace directly to a commit in v0.8.0..dev. The 3 that didn't match my grep all verify on inspection: #1639 (display_label present in models.py/routers/agents.py, siblings #1640–#1642 merged), #1652 (the /enterprise/client-portal view is gone from dev; shipped under 1bfad484), #1598 (fixed by PR #1588 → 55dd9009, confirmed in range). All three carry status-in-dev, i.e. machine-set on merge to dev; they stay OPEN until the cut auto-closes them.
• The only two refs with no merged commit are #1741 and #1759 — precisely the two the Known-limitations block declares not fixed. Internally consistent.
• Enterprise refs: 26 distinct; sampled 7, all resolve with matching titles (ent#12, #124, #151, #180, #184, #206, #219).

VERSION

0.8.0 → 0.8.5 is correct and consistent — consumed by docker/backend/Dockerfile (ARG/ENV + COPY ../../VERSION /app/VERSION) and build-base-image.sh (image tag). No stale 0.8.0 left anywhere except the two intentional v0.8.0...v0.8.5 compare links. Matches the established bump-at-release pattern and the cited #1528 precedent (same shape: VERSION + release notes → dev).

Checks

Check	Status
Base branch	✅ dev
Size	✅ 2 files
Commit message	✅ conventional
Security scan	✅ clean (secrets/emails/IPs/creds all 0)
Build + config packaging	➖ no backend module, no os.getenv, no infra files
Docs required	➖ docs + VERSION only, no code

Minor, non-blocking: the header stat line says 619 files; actual is 617 (v0.8.0..dev) or 618 including this PR's own two. Commit count (773) and +97.7k/−14k are exact. Cosmetic only — worth a one-character fix if the notes get regenerated at the cut, not worth holding the release.