Thread of Hope all-rings planning toggle

[EtherealCarnivore]

What this does

Adds a single tree-view hotkey for Thread of Hope planning:

• T toggles "show all 5 rings" mode for any allocated Thread of Hope socket.

While the mode is on, ToH is treated as if every Variable ring were equipped, so nodes inside any of the five rings become allocatable via the existing intuitive-leap mechanic, regardless of the variant the player actually picked. Nodes are also tinted by the colour of the ring they sit in, matching how the in-game jewel highlights its affected passives.

State is session-only (not saved to build XML), so loading a saved build never lands you in a mystery "all rings" state.

Discoverability

The hotkey is surfaced in two places:

• A small first-time hint appears top-left whenever a Thread of Hope is socketed and the user has never pressed T. The first press dismisses the hint forever (persisted on main.toHHintDismissed alongside the other Misc settings in Settings.xml).
• The Thread of Hope item tooltip gains a display-only Tip: Press T... line directly under Radius: Variable. This line is added via tooltip:AddLine and is never written to item.rawLines, so import/export and build-share codes are unaffected.

How it works

A new PassiveSpec:GetEffectiveRadiusIndices(item) helper reads the override from build.treeTab.viewer.toHRingMode and returns either:

• { item.jewelRadiusIndex } by default (unchanged behaviour)
• { 6, 7, 8, 9, 10 } (the five Variable ring indices) when the toggle is on for a Variable-radius jewel

All four call sites that previously used item.jewelRadiusIndex directly now route through this helper:

• BuildAllDependsAndPaths, populating intuitiveLeapLikesAffecting
• BuildAllDependsAndPaths, orphan-pruning check (the load-bearing fix; without it, freshly-allocated leap nodes were getting deallocated by the same pass that allocated them when the override didn't match the variant)
• NodesInIntuitiveLeapLikeRadius
• PassiveTreeView ring rendering

The override only kicks in when item.jewelRadiusLabel == "Variable", so other radius-using uniques (Impossible Escape, etc.) are unaffected.

Visual changes

• The Massive jewel-radius colour was changed from dark green (^x0B9300) to gold (^xFFD700). With all five Variable rings drawn at once, the Medium ring's teal (^x66FFCC) and the old Massive's dark green were both reading as shades of green and were hard to tell apart. Gold keeps all five rings clearly distinguishable. The same colour is shared by the regular Massive Cluster Jewel radius since both come from data.jewelRadii. Happy to revert to the original palette if preferred.
• A pre-pass over spec.jewels builds a nodeId -> ring colour map when the toggle is on, and the existing overlay-tinting block applies it as a fallback when no hover-based tint is active.

Changes

• src/Classes/PassiveSpec.lua: GetEffectiveRadiusIndices helper; the 3 call sites now route through it
• src/Classes/PassiveTreeView.lua: T keybind, ring drawing + node tinting when the toggle is on, first-time hint
• src/Classes/ItemsTab.lua: Variable-radius tooltip hint line (display-only)
• src/Modules/Main.lua: main.toHHintDismissed load/save in the Misc element
• src/Modules/Data.lua: Massive radius colour swap

Steps taken to verify

• T toggles all 5 rings on a build with a Variable Thread of Hope; clicking unconnected nodes inside any ring allocates them as a leap-jump (1 point) regardless of the actual variant
• Pressing T again hides the rings and reverts dependency calcs to the variant-only radius
• Nodes inside each ring render in that ring's colour while the toggle is on
• First-time hint appears top-left when a ToH is socketed; vanishes for good after the first T press; stays dismissed across PoB restarts
• Tooltip hint line shows under Radius: Variable, and the export build code does not contain it
• Default behaviour (toggle off) is unchanged; no new state lands in saved build XML
• Other radius-based uniques (Impossible Escape, etc.) unaffected
• Hot-reload (F5) works without errors