Redesign annotate page with improved layout and mobile support

[maxachis]

#405

Summary

• Two-panel layout: Sticky screenshot preview on the left, annotation wizard on the right (stacks on mobile)
• Stepper navigation: Replaced basic tab bar with numbered circle stepper showing progress, completed/skipped states
• Consistent amber accent theme: All interactive/selected states use amber instead of wine for readability on dark backgrounds
• Zoomable screenshot: Hover magnifier on desktop (disabled on touch devices), click/tap to open full-size
• Mobile optimizations: Collapsible preview card, compact screenshot (4:3), reduced padding, single-column record type grid
• Cleaned up: Removed <br> spacer hacks, unified notice patterns, converted components to Composition API

Test plan

• Verify two-panel layout on desktop (lg+ breakpoint)
• Verify single-column stacked layout on mobile
• Test collapsible preview toggle on mobile (smooth animation, URL stays visible)
• Test screenshot hover magnifier on desktop (lens follows mouse, click opens full-size)
• Confirm magnifier is disabled on touch devices (no lens, no hint icon, tap opens full-size)
• Walk through full annotation flow: URL Type → Location → Agency → Record Type → Name → Confirm
• Verify stepper shows correct states (active, completed, skipped, disabled)
• Check all selected states use amber (buttons, radio options, pills)
• Test content warning modal and cookie reminder dismissal
• Verify SupplementalInfo collapsible panel opens/closes

🤖 Generated with Claude Code

[josh-chamberlain]

This is a good start! I like much of what it did. Other stuff is either a lateral move or actively worse, so please allow me to smack down some of its ideas. Once these are resolved, I think it's ready for dev testing and likely quick approval.

• For it to address #405, it needs to address all the requirements. In particular the rounded corners irk me.
• In general, we should not be using scoped styles and creating classes—almost ever. This will be very important to reinforce with Claude. We're using Tailwind, and the Tailwind philosophy (good reading!). Styles are separate from structure. It makes it much easier to see what's going on, rather than scrolling up and down to see which styles are applied to what. And if we're styling semantically, we don't need to create our own styles almost ever—tailwind has done that for us. Joy. I would love to see all those classes moved inline. It even supports states.
• In general, for colors of buttons and their hierarchy, reference the map's sidebar. This was fine-tuned recently with an eye for compactness and cascading hierarchy, as well as looking nice in both dark and light mode.
• Never amber or orange, please! Primary action buttons are gold. We have a range of golds and goldneutrals that are intended to show buttons of lower hierarchy or rendering information that is not clickable in wines and wineneutrals, all while being readable on any background imaginable.
  
• On this topic, things should only be gold if they're actively clickable—we dim them if they're inactive, and they are only gold if they are the primary button button for the workflow. The design system already has preset components for button-primary and -secondary and such, and they can be modified from there, but it's a great starting point. We want to give people a cue for what the intended action is—as it stands, the multiple gold (or amber) things are competing for attention; what's most important?
• The dark wine text is not a good look on the black background. We have a whole set of lovely tints and shades of wine, gold, wineneutral, and goldneutral. It may be best to reference the map sidebar for hints as to how to use with those.
  
• Tinted backgrounds reduce color contrast, which reduces readability and strains the eyes. If a background is tinted, it should be done with a very light touch—i.e. an -800 tint on a -900 background.
• The inline SVGs are quite the sight—but we should just use fontawesome icons for those. Claude is usually pretty good at picking out appropriate ones and adding them properly.
• The container under the header, in which live such components as select a location, does not need its own tinted background and padding. Those items are united by their placement, and don't need to be boxed off from the header or prev/next buttons.

[labradorite-dev]

Probably can close this one out now right ?

[maxachis]

Probably can close this one out now right ?

You bet we can!