fix: plan card unreadable on shopping list in dark mode

[dubadub]

Summary

• On the shopping list page in dark mode, plan/menu entries rendered as a bright white card with nearly-invisible light-gray text (see issue screenshot).
• Root cause: plan cards use `bg-gradient-to-r from-indigo-50 to-purple-50`, but `templates/base.html` only had dark-mode overrides for other gradient combos (orange/yellow, gray/orange, green/blue, blue/purple, purple/pink, green/emerald). The indigo/purple combo was missed, so the background stayed light while the inner text classes (`text-gray-800`, `text-gray-600`, etc.) picked up their dark-mode light colors.
• Fix: add dark-mode overrides for the indigo/purple gradient and the matching `border-indigo-200` so plan cards match the other shopping-list cards.

Test plan

• Enable dark mode in the web UI
• Open `/shopping-list` with a plan/menu selected (e.g. "3 Day Plan" from the seed data)
• Verify the plan card has a dark background and readable text for the plan name, nested recipes, and `(×N)` scale
• Verify regular (non-plan) recipe cards still render correctly in dark mode
• Verify light mode is unchanged

[claude]

Code Review

Summary: This correctly identifies and fixes the missing dark-mode override for the indigo/purple gradient used on plan cards. The approach is consistent with the existing pattern in base.html.

What works well

• Root cause analysis in the commit message is clear and accurate.
• The fix follows the established pattern for gradient overrides (lines 102-121 in base.html).
• Adding a comment calling out the specific use case (plan cards) improves maintainability of what is otherwise an opaque block of CSS overrides.

Issues to consider

1. Border color cascade interaction (minor)

The gradient selector sets border: 1px solid #374151 (gray-700), but the separately added .dark .border-indigo-200 rule immediately overrides border-color to #4c1d95 (violet-900). If a plan card element carries both classes — which appears to be the case — the effective border will be #4c1d95, not #374151. This may be intentional (a purple accent border), but it is worth confirming visually. If the gray border was intentional, the .dark .border-indigo-200 rule should be removed or the two rules consolidated.

2. Indigo vs purple border color (cosmetic)

.dark .border-indigo-200 and .dark .border-purple-200 both use #4c1d95, which maps to Tailwind violet-900/purple-900. The Tailwind indigo-900 equivalent is #312e81. The difference is subtle and likely unnoticeable, but flagging it in case palette consistency matters.

3. Fragility of the gradient-enumeration approach (pre-existing, not introduced here)

Every new gradient combination added to a template requires a corresponding entry in this block — and this PR is evidence that entries can be missed. A longer-term improvement (outside scope here) could be a single rule targeting any -50 shade gradient under .dark, or using CSS custom properties for theme colors. Not a regression introduced by this PR.

Test plan coverage

The test plan covers the happy path and a light-mode regression check. Also worth verifying that nested recipe entries within the plan card (the (×N) scale label and nested recipe names) are readable, since those may rely on text-color classes that inherit dark-mode defaults indirectly.

Verdict: Correct fix, follows existing conventions. Resolve the border cascade question before merging.