chore(release): bump to 2026.07.0

[vpetersson]

Issues Fixed

N/A — routine release version bump.

Description

Bump the Anthias version to 2026.07.0 (CalVer YYYY.0M.MICRO; July 2026, micro resets to 0) ahead of cutting the next release.

• package.json + pyproject.toml: 2026.07.0
• uv.lock: regenerated via uv lock (anthias 2026.6.3 → 2026.7.0, no dependency churn)

Checklist

• I have performed a self-review of my own code.
• New and existing unit tests pass locally and on CI with my changes.
• I have done an end-to-end test for Raspberry Pi devices.
• I have tested my changes for x86 devices.
• I added a documentation for the changes I have made (when necessary).

🤖 Generated with Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[Copilot]

Pull request overview

Bumps Anthias’ release version to 2026.07.0 across the Python project metadata and the JS toolchain metadata, and updates the lockfile entry to match the normalized Python version representation.

Changes:

• Update Python package version in pyproject.toml to 2026.07.0.
• Update JS package version in package.json to 2026.07.0.
• Update uv.lock’s editable anthias package version to the normalized form 2026.7.0.

Reviewed changes

Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.

File	Description
uv.lock	Updates the locked editable anthias package version to match the new release (normalized form).
pyproject.toml	Bumps the Python project version to 2026.07.0.
package.json	Bumps the JS/package metadata version to 2026.07.0.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[vpetersson]

End-to-end testbed validation ✅

Ran a full integrated-stack e2e across all three hardware classes before cutting the release. This bump only changes a version string, so the runtime under test is master HEAD's built image set 6bbe55b (the 2026.07.0 release will ship exactly these server/viewer/redis images).

Deployed 6bbe55b-<board> to each testbed (compose tag bump → pull → up -d → prune), then drove every supported asset type through the real viewer and verified load and playback.

Result matrix

Asset type	x86 (amd64, cage/Wayland)	Pi 5 (cage/Wayland)	Pi 4 (eglfs)
Image	✅ screenshot	✅ screenshot	✅ log-verified
Video	✅ H.264 1080p, screenshot	✅ HEVC 1080p, screenshot (HW decode)	✅ H.264 1080p, HW decode /dev/video10, dropped=0
Webpage	✅ example.com rendered	✅ example.com rendered	✅ log-verified

All 4 containers (server/viewer/celery/redis) healthy on every board; error/traceback/crash scan over the run came back clean (the only hits were a self-inflicted duration=60 400→corrected, and an ffprobe -v error INFO line).

Notes / method

• Video codecs per board: H.264 for x86/Pi 4 (H.264 = Pi 4's HW-decoded codec via /dev/video10), HEVC for Pi 5 (its Hantro G2 HW path; the codec gate rejects H.264 uploads there). Source clip transcoded on the dev host — testbeds never transcode.
• Pi 4 is eglfs (no Wayland/compositor screenshot). Verified through viewer logs (Showing asset … (video)), the open /dev/video10 decoder fd, and playback-stats.log advancing with dropped=0.
• x86 currently has no monitor attached (all DRM connectors disconnected), so pixel capture used a temporary WLR_BACKENDS=headless virtual output (reverted afterward). The initial video frame captured black — that was just pre-roll; spaced re-captures showed real motion (mean luma 162→96→94).
• Pre-existing testbed sample assets had expired end_date windows (2026-06-14) → is_active:false; extended to validate. Not a code issue.
• Testbeds restored afterward: created x86 assets deleted, headless override removed, all assets re-disabled per idle-testbed policy. All three left on 6bbe55b.

⚠️ Release-cut heads-up (not a blocker for this PR)

Current master HEAD b46750d (#3090, rpi-imager) has no anthias-{server,viewer,redis}:b46750d-* images in GHCR — that commit didn't touch paths that trigger docker-build.yaml. When cutting v2026.07.0, make sure the tagged commit has a completed Docker Image Build, or the disk-image workflow's preflight will fail and skip the balena deploy.