`editor.selectionHighlightBorder` equals `editor.background` in all six variants, so the border never renders

[dineshmistry]

editor.selectionHighlightBorder is set to editor.background in every variant, making the border invisible

Summary

In all six theme variants, editor.selectionHighlightBorder is assigned the exact
same value as editor.background. The border is drawn, but has zero contrast
against the surface behind it, so it never renders visibly.

This is likely the root cause of #89 ("multi select or single select a word,
high light can more clearly?"), which reports the symptom but was never
diagnosed. Happy to have this closed as a duplicate if you would rather keep the
discussion there.

Affected variants

Variant	editor.selectionHighlightBorder	editor.background
Rosé Pine	#191724	#191724
Rosé Pine (no italics)	#191724	#191724
Rosé Pine Moon	#232136	#232136
Rosé Pine Moon (no italics)	#232136	#232136
Rosé Pine Dawn	#faf4ed	#faf4ed
Rosé Pine Dawn (no italics)	#faf4ed	#faf4ed

All six collide, so this looks like the token was set to the base background
deliberately as a way of "disabling" it, rather than being an isolated typo.

Steps to reproduce

1. Select Rosé Pine (any variant).
2. Open a file where a word occurs several times.
3. Double-click one occurrence to select it.
4. The other occurrences are highlighted, but have no visible outline.

Expected

Occurrence highlights are outlined with a border distinguishable from the editor
background, as the token intends.

Actual

The border is the editor background colour, so no outline appears at any zoom
level or contrast setting.

Impact

Low severity, and it degrades rather than breaks: editor.selectionHighlightBackground
is #6e6a8633, a translucent fill that still reads, so occurrences remain findable.
The outline is simply lost. Worth noting because the fill alone is quite subtle at
20% alpha, and the border is what the theme spec expects to carry the emphasis.

Suggested fix

Point the token at Highlight Med, which is already part of each palette and is
what other separators in the theme use:

Variant	Suggested value
Rosé Pine	#403d52
Rosé Pine Moon	#44415a
Rosé Pine Dawn	#dfdad9

If the intent was in fact to suppress the border and rely on the fill alone,
#0000 would express that explicitly. The theme already uses #0000 for other
borders it deliberately hides (editorGroup.border, panel.border, tab.border),
and #117 confirms the borderless look is deliberate, so using the background
colour here is inconsistent with that established convention either way. Whichever
value is chosen, the intent would be clearer than an opaque colour that happens to
match the background.

Environment

• Extension: mvllow.rose-pine 2.15.2
• VS Code: 1.131.0
• macOS 26.6 (arm64)

Workaround

"workbench.colorCustomizations": {
  "[Rosé Pine]": {
    "editor.selectionHighlightBorder": "#403d52"
  }
}