frontend: hover-revealed controls stay put where hovering is impossible (task 2697)

A finger cannot hover, and on a note card the hover toolbar is the only way to
pin, colour or archive — so on a phone those notes could not be acted on at all.
Same for deleting a checklist item, a saved view, an attachment or a preview.

Marked rather than rewritten inline: one `.hover-reveal` class on the five
elements and a single rule that says what it is for. The `group-hover:` reveal
stays in the markup because the trigger differs per component (named groups);
only the fallback is shared. `@media (hover: none)` asks the device directly,
which is more honest than inferring from viewport width — a narrow window on a
laptop still hovers, and a large tablet still doesn't. It sits after the Tailwind
directives so it beats the opacity-0/pointer-events-none utilities on source
order without !important.

Tap targets follow the same shape: p-1.5 around an 18px icon lands near 30px,
which is fine for a cursor and too small for a thumb. Bumped to 44px on coarse
pointers only, so desktop chrome doesn't inflate.

The drag grip is deliberately NOT revealed yet. Reordering still uses HTML5
drag-and-drop, which never fires from touch, so showing the handle would only
promise something that does nothing. It comes with the pointer-events rewrite.

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

frontend/src/components/AppShell.vue

@@ -388,7 +388,7 @@ async function signOut() {
               <span class="flex-1 truncate">{{ f.name }}</span>
               <button
                 type="button"
-                class="text-neutral-400 opacity-0 hover:text-red-500 group-hover/view:opacity-100"
+                class="hover-reveal text-neutral-400 opacity-0 hover:text-red-500 group-hover/view:opacity-100"
                 :aria-label="`Delete view ${f.name}`"
                 @click.prevent.stop="removeView(f)"
               >