fix: include rendered_at in 304 cache check so re-renders invalidate

After re-cropping an image, the renderer regenerates the .bin and
advances the asset's rendered_at, but the device's 304 short-circuit
still matched on (image_id, orientation) only — so the device kept
serving the old upside-down/stale bytes from its local cache despite
the server having freshly-rendered correct ones.

Adds device.current_rendered_at, populated whenever a 200 response is
served, and tightens the 304 condition to require all three (image id,
orientation, rendered_at) to match. The asset lookup now happens before
the 304 check so its rendered_at is in scope for the comparison.

No firmware change — this is server-side cache logic. Existing devices
get null current_rendered_at after the migration; their next poll falls
through 304 and re-fetches once, then the cache is in sync.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

migrations/Version20260507230000.php

@@ -0,0 +1,27 @@
+<?php
+
+declare(strict_types=1);
+
+namespace DoctrineMigrations;
+
+use Doctrine\DBAL\Schema\Schema;
+use Doctrine\Migrations\AbstractMigration;
+
+final class Version20260507230000 extends AbstractMigration
+{
+    public function getDescription(): string
+    {
+        return 'Add device.current_rendered_at so 304 cache check can detect re-renders';
+    }
+
+    public function up(Schema $schema): void
+    {
+        $this->addSql('ALTER TABLE device ADD current_rendered_at TIMESTAMP(0) WITHOUT TIME ZONE DEFAULT NULL');
+        $this->addSql("COMMENT ON COLUMN device.current_rendered_at IS '(DC2Type:datetime_immutable)'");
+    }
+
+    public function down(Schema $schema): void
+    {
+        $this->addSql('ALTER TABLE device DROP COLUMN current_rendered_at');
+    }
+}