Issue numbers in comments are painted as color swatches

🤖 Claude (via Claude Code):

## Description

An issue reference in a comment gets a colour swatch painted in front of it, in **any** language — this was
first seen in a Java file. Monaco registers a default document colour provider for `'*'`
(`defaultDocumentColorProvider.js`), and with the default `defaultColorDecorators: 'auto'` it runs for every
model whose language has no colour provider of its own. Its regex matches `#` + 3/4/6/8 hex digits preceded
by whitespace or a quote, with no awareness of comments or strings, so `/** GH #130: … */` renders with a
dark square before the number, as if `#130` were the colour `#113300`.

CSS-family files reach the same result by the other path: there the language's own colour provider wins, and
it likewise does not exclude comments.

An issue reference is far more common in this editor than a literal colour, and a swatch inside a code buffer
earns nothing the rendered preview does not already do better.

## Steps to reproduce

1. Open a `.java` file in a Monaco file tab (any language without its own colour provider works; `.css`
reproduces via the CSS provider instead).
2. Add a comment containing a three- or six-digit issue reference, e.g. `/** GH #130: keep this in sync */`.
3. Look at the comment.

## Expected behavior

The comment renders as plain comment text — no colour decorator.

## Actual behavior

A colour swatch is drawn immediately before `#130`.

## Environment

- OS: macOS 26.6.2
- Bun version (`bun --version`): 1.4.0
- Node version (`node --version`): v26.8.1
- ThinkRail version / commit: `1e939abc` (monaco-editor 0.55.1)

## Fix

Already written on `claude-code-integration` as c7b35ff77a3a9d9d289dc440dede98134121d75f: `colorDecorators:
false` in `sharedEditorOptions`, which switches off both paths. Not yet on `main` and no PR is open for it.

Note that the commit message, the `apps/web/src/panels/SPEC.md` note, and the e2e test it adds all describe
this as CSS-specific — that scope is too narrow and should be corrected to the `'*'` default provider before
it lands.

---

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Start by reviewing the existing c7b35ff77a3a9d9d289dc440dede98134121d75f change on claude-code-integration and the sharedEditorOptions setting. Check the e2e test and the apps/web/src/panels/SPEC.md note, broadening their CSS-specific wording to cover the default '*' provider. Done means the setting and documentation reflect the reported behavior and the e2e test passes.

Written by the indexing model from the issue text.