fix(handy): gleiches Logo, schiebbare Apps, Widgets in voller Breite

Drei Sachen, die Marc aufgefallen sind:

Das Quadrat im Logo war in der HoneyBar in voller Groesse, in der Menueleiste
klein und angehoben — nebeneinander sah das wie zwei verschiedene Logos aus.
Jetzt beide 10px.

Bei vielen Apps quetschte das Flex-Raster die Namen zusammen, statt den Streifen
schiebbar zu machen: flex-shrink stand auf 1. Jetzt schiebt man seitwaerts, in
beiden Leisten, mit einem Schatten am rechten Rand als Hinweis. Am Handy war
das der Unterschied zwischen "sechs Apps erreichbar" und "drei Buchstabenreste".

Und die Widgets waren einspaltig auf 320px begrenzt, waehrend das Systemfenster
die volle Breite nahm — drei verschieden breite Kaesten untereinander sehen aus
wie ein Fehler. Dazu wird aus der Kachelwand am Handy eine Liste: sechs Apps
passen jetzt auf einen Bildschirm statt auf drei.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

IDEAS.md

@@ -281,6 +281,56 @@ Zu prüfen ist dabei, was sonst noch inline gesetzt wird: die Lage der HoneyBar
 selbst und der Innenabstand, den sie der Seite verpasst. Über die CSSOM gesetzte
 Stile (`el.style.x = …`) fallen nicht unter die CSP — was im Markup steht, schon.
 
+### Bild-Widget — Marcs Idee (29.08.2026)
+
+Ein Widget, das ein Bild zeigt: hochgeladen oder als Adresse eingetragen. Genau
+**eines je Nutzer**; ein neues ersetzt das alte, ohne Verwaltung und ohne Liste.
+
+Reizvoll daran ist, dass es das erste Widget wäre, das nichts abfragt, sondern
+etwas *ist* — der Schreibtisch bekommt damit einen persönlichen Zug, den keine
+Datenanzeige liefert.
+
+Zu klären, wenn es soweit ist:
+
+- **Ablegen.** HoneyOS speichert bisher nur eine JSON-Datei. Ein Bild heisst:
+  Ordner unter `/data`, Grössengrenze, erlaubte Typen. SVG ist heikel — es kann
+  Skripte enthalten und darf nicht einfach durchgereicht werden.
+- **Ausliefern** mit Versionsanteil in der Adresse, sonst bleibt beim Austausch
+  das alte im Zwischenspeicher hängen.
+- **Adresse statt Upload** ist billiger zu bauen, holt aber eine fremde Anfrage
+  auf jede Seite mit HoneyBar. Für den Schreibtisch unkritisch; sollte das Bild
+  je in die HoneyBar wandern, wäre es eine Anfrage aus jeder App.
+- **Zuschneiden?** Ein Bild in einem festen Rahmen ist entweder verzerrt oder
+  beschnitten. `object-fit: cover` und gut — Zuschneiden von Hand ist ein
+  eigenes Stück Arbeit.
+- Passt zum Aufnehmen eigener App-Logos (1.3): dieselbe Ablage, dasselbe
+  Ausliefern. Zusammen bauen spart die Hälfte.
+
+### Widgets verschieben, Reihenfolge im Server — Marcs Idee (29.08.2026)
+
+Widgets per Ziehen umsortieren, die Reihenfolge liegt beim Nutzer auf dem
+Server — also auf jedem Gerät gleich.
+
+**Der Haken ist nicht das Ziehen, sondern die zwei Betriebsarten.** Im
+Terminal-Modus stehen die Widgets in einer Spalte (eine Reihenfolge), im
+Desktop-Modus als Schilder auf der Fläche (dort wären Koordinaten das
+Natürliche). Eine gemeinsame Liste für beides ist die einfachere Zusage: eine
+Reihenfolge, in beiden Ansichten dieselbe. Freie Plätze auf dem Schreibtisch
+wären das schönere Ziel, aber dann liegen zwei Anordnungen im Server, und beim
+Wechsel muss man sich entscheiden, welche gilt.
+
+→ **Vorschlag: eine Liste, beide Ansichten folgen ihr.** Freie Plätze später,
+falls sie je fehlen.
+
+Am Handy: **Ziehen ist dort kein Standard** — HTML5-Drag löst per Berührung
+nicht aus. Entweder Zeigerereignisse selbst behandeln (wie beim Fensterziehen
+schon gebaut) oder am Handy Pfeiltasten statt Ziehen anbieten. Nicht vergessen:
+Ohne das ist die Funktion am Handy schlicht nicht da.
+
+Voraussetzung ist ein Widget-Verzeichnis — heute stehen Benutzer und Wetter
+fest im HTML. Sinnvoll zusammen mit dem Widget-Rahmen (1.6) zu bauen, nicht
+davor.
+
 ### Widgets in der HoneyBar selbst
 
 Bisher sind Widgets als Fenster auf dem Schreibtisch gedacht. Der Schreibtisch