Custom theme diffAdded/diffRemoved overrides still ignored in file-diff view (v2.1.236); light-ansi base also renders single-word diffs invisible

Bug Description

Custom theme diffAdded/diffRemoved/diffAddedDimmed/diffRemovedDimmed/diffAddedWord/diffRemovedWord overrides are still ignored by the file-diff renderer (Edit/Write tool-call diff cards). This is the same root cause reported in #66937 and #69445 (both closed: #66937 as stale/not-planned, #69445 as a duplicate of #66937), still reproducible on the current version.

Version: 2.1.236 (macOS, Ghostty terminal, termguicolors/truecolor enabled)

Repro

~/.claude/themes/mono.json:

{
  "base": "light-ansi",
  "overrides": {
    "text": "#262626",
    "diffAdded": "#cce8cc",
    "diffRemoved": "#f7d4d4",
    "diffAddedWord": "#9fd89f",
    "diffRemovedWord": "#f0aaaa"
  }
}

1. /theme → select the custom theme (confirms the file parses).
2. Edit any file so a single short word changes on one line (e.g. change one word in a sentence, or one JSON value).
3. Observe the tool-call diff card.

Expected: Added/removed lines use the overridden diffAdded/diffRemoved backgrounds, and changed-word text is visible.

Actual, two related symptoms:

1. Overrides are ignored outright — the diff always renders with the base preset's own stock diff colors, exactly as described in #66937/#69445 (root cause there: the diff component resolves via currentTheme, which collapses custom:<slug> to the base preset name and discards overrides, instead of resolvedTheme).
2. New finding not covered by the earlier reports: under base: "light-ansi" specifically, a single-word (or otherwise short) added-line diff renders with no visible text at all — not just the wrong color, but fully invisible (apparently white-on-white), reproduced consistently across multiple independent one-word edits. Removed-line text (red) always renders fine; only the added side is affected. Switching base to "light" (non-ANSI, fixed-hex preset) avoids the invisible-text issue and gives correct green/red diff backgrounds — but as a side effect, all other UI accent/status colors and code-block syntax highlighting switch from the terminal's own (often intentionally monochrome) ANSI palette to the preset's fixed hex palette, which cannot be brought back to monochrome through overrides either, since those apparently aren't read by the same code paths.

Impact: Anyone building a low-color/monochrome custom theme is stuck choosing between (a) light-ansi/dark-ansi base, which respects the terminal's ANSI palette for everything else but makes some diffs unreadable, or (b) a non-ANSI base, which fixes diff readability but forces the base preset's full color palette onto code syntax highlighting and other accents, none of which is currently override-able.

Request: Fix the diff-view (and ideally syntax-highlighting) color resolution to read from resolvedTheme (overrides included) instead of currentTheme, per the root cause already identified in #69445. That would resolve both the original override-ignoring issue and this invisible-text variant in one fix.

Related: #66937, #69445