chore(deps): bump vite-plus to v0.2.2

[fengmk2]

Summary

Bump vite-plus and related packages to the pkg.pr.new prerelease build for v0.2.2 (registry-bridge commit build) to smoke-test the prerelease.

• vite-plus + vite (alias to @voidzero-dev/vite-plus-core) and vitest pinned to the commit build across deps / overrides / catalogs
• minimumReleaseAge enabled with the vite-plus / @voidzero-dev/* / oxc / oxlint stack excluded
• .npmrc (or .yarnrc.yml) points the package manager at the registry bridge (prerelease scaffolding)

Test plan

• CI passes

[gemini-code-assist]

Code Review

This pull request introduces support for client-supplied stop_sequences in Anthropic messages, disables repetition cutoff parameters by default to align with vLLM, and adds support for the gemma4_unified model type. It also addresses a compilation hazard by replacing fused addmm with explicit matrix multiplication and addition, and resolves Qwen3.5-VL vision issues by implementing interleaved multimodal rotary position embeddings and proper M-RoPE delta tracking. The review feedback highlights opportunities to optimize memory allocation in persistence.rs by avoiding unnecessary vector copies, and to improve robustness in language.rs by adding defensive checks against division-by-zero and out-of-bounds panics.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

Calling .to_vec() on the slice returned by shape()? allocates a new Vec and copies all elements unnecessarily. You can call .last() directly on the slice to avoid this allocation.

            let weight_last = *weight.shape()?.last().ok_or_else(|| {\n                Error::from_reason(format!(\"gemma4 {key} load: weight is 0-rank\"))\n            })?;\n            let scales_last = *scales.shape()?.last().ok_or_else(|| {\n                Error::from_reason(format!(\"gemma4 {key} load: scales is 0-rank\"))\n            })?;

[gemini-code-assist]

If head_dim is less than 2, half_usize will be 0, leading to a division-by-zero panic during the modulo operation j % half_usize. Additionally, if mrope_section has fewer than 3 elements, accessing mrope_section[1] or mrope_section[2] will cause an out-of-bounds panic. Adding defensive checks for these cases ensures robustness.

Suggested change

	let cos_shape = cos.shape()?; // 1 FFI call — cache and reuse below
	let batch_size = cos_shape[1];
	let seq_len = cos_shape[2];
	let head_dim = cos_shape[3];
	let half = head_dim / 2;
	let half_usize = half as usize;
	let cos_shape = cos.shape()?; // 1 FFI call — cache and reuse below\n let batch_size = cos_shape[1];\n let seq_len = cos_shape[2];\n let head_dim = cos_shape[3];\n let half = head_dim / 2;\n let half_usize = half as usize;\n\n if half_usize == 0 {\n return Err(Error::from_reason(format!(\n \"head_dim must be at least 2, got {}\",\n head_dim\n )));\n }\n\n if mrope_section.len() < 3 {\n return Err(Error::from_reason(format!(\n \"mrope_section must have at least 3 elements, got {}\",\n mrope_section.len()\n )));\n }