v0.27.3:0 - cap image resolution (fix oversized-image 400); remove vision-check button

A 12MP photo expands past vLLM's ~4096-image-token limit -> 400. Cap via
--mm-processor-kwargs max_pixels in the qwen36 recipe so big images auto-
downscale server-side for every /v1 consumer (verified live: 400->200).
Remove the v0.27.2 in-dashboard vision-check button per owner request; the
vision badge already signals capability.

package/startos/versions/v0_1_0.ts

@@ -1,10 +1,10 @@
 import { VersionInfo, IMPOSSIBLE } from '@start9labs/start-sdk'
 
 export const v0_1_0 = VersionInfo.of({
-  version: '0.27.2:0',
+  version: '0.27.3:0',
   releaseNotes: {
     en_US:
-      'v0.27.2:0 — vision support is now visible and testable in the dashboard. (1) Qwen3.6-35B-A3B is a vision model (it reads images, including OCR), but its card was mislabelled text-only — it now shows the "vision" badge. (2) NEW: a "Vision check" button appears on the running model\'s card when it supports images. Upload a picture (e.g. a business card) with a prompt and see what the model reads back, right in the dashboard — confirmed reading a business card cleanly on the Qwen3.6 vision model. It uses the same on-LAN /v1 endpoint your apps already use, so nothing leaves your network. No consumer-API changes; the /v1 proxy, swap, and coordination APIs are unchanged.',
+      'v0.27.3:0 — Qwen3.6 vision now works end-to-end, including full-size phone photos. (1) Qwen3.6-35B-A3B reads images (e.g. business-card OCR) and now shows a "vision" badge on its card. (2) Fix: large/high-resolution images (e.g. a 12-megapixel phone photo) were being rejected by the model with a 400 error — a single big image expands to more vision tokens than vLLM allows. The Qwen launch now caps image resolution (max_pixels) so oversized images are automatically downscaled to a size the model accepts; the dashboard, Open WebUI, and any downstream app can now send full-size photos to the /v1 endpoint without errors, and OCR stays sharp. No consumer-API changes; the /v1 proxy, swap, and coordination APIs are unchanged.',
   },
   migrations: {
     up: async ({ effects }) => {},