Fix cache-related correctness issue in power report

[AdamZ-8113]

Description of the problem being solved:

The passive power report can show incorrect gains or losses because it reuses calculation results for nodes with identical modifier text, even when allocating those nodes has different effects.

This can also hide useful nodes entirely when an incorrect "0 DPS" result filters them out of the report.

This fix attempts to preserve the speed gained from caching, but in some cases I observed up to a 9% slower report. The cache now accounts for current modifiers and node/mastery type. Nodes affected by radius jewels, tattoos, or timeless-jewel transformations are calculated separately, as are nodes with structured modifiers such as granted skills. This retains reuse for equivalent nodes while calculating the affected cases separately.

In the linked Fireball build, the +10 Dexterity node directly right of Sentinel (16167) was missing from the Full DPS report. Direct calculation gives it approximately 7.69 million DPS, which the corrected report now shows.

Steps taken to verify a working solution:

• Used Codex to compare unchanged upstream, the fix, and a reference that recalculates every candidate without report-cache reuse. Tested 82 build/report/depth combinations across nine saved builds, for 246 report runs. Every fixed result matched the reference exactly; upstream had incorrect results in 28 combinations across five builds.
• Covered Full DPS, Hit DPS, Life, Effective Hit Pool, Offence/Defence, Mana, Armour, Energy Shield, Dexterity, Ignite DPS, Minion Life, and Minion Effective Hit Pool, using depths 0, 1, 3, 5, 10, and 'All'
• Compared individual nodes, paths, mastery effects, cluster notables, report rows, and report maxima. Builds included jewel-radius effects, tattoos, timeless jewels, clusters, and player/minion setups on 3.28 and 3.29 trees.
• Added regressions for identical modifiers inside/outside a jewel radius, mastery bonuses leaking into cluster notable results, and passive-effect modifiers added after initial parsing. All three fail against unchanged upstream and pass with the fix. The radius test also checks rebuilding after removing the jewel.
• Full automated suite: 587 successes, zero failures or errors.
• Separate three-pass native benchmarks across five builds, using Full DPS at All depth, measured approximately 4.4% longer runtime overall based on summed per-build medians. The largest per-build increase was 9.6%.

Link to a build that showcases this PR:

https://pob.codes/b/GhW2hQJvqyF

Use Full DPS at depth 1 or greater and look for Dexterity node 16167, directly right of Sentinel and below the Exceptional Performance / Window of Opportunity wheel.

Before screenshot:

The Dexterity node at depth of 1 is missing

After screenshot:

Now it's displayed.

[PJacek]

This seems to be a slightly different implementation than #10377. I'm not sure which one is better.

[AdamZ-8113]

Darn. I didn't realize another PR was up for fixing the same issue. I asked Codex to run the same corpus of tests across both PRs. It looks like #10377 is faster but it still has correctness issues.

Codex summary:
Compared this PR against the amended version of #10377 (ec82794a558d8aca836ad4695753855a8833d79c).

• Performance: Fix Node Power giving nodes another node's score #10377 took about 6.6% less time across five builds using Full DPS at All depth, with three warmed passes per build.
• Correctness: This PR matched independent calculations in 82/82 combinations across nine builds; Fix Node Power giving nodes another node's score #10377 matched 77/82.
• The five mismatches were in this Shatter Shard build: Full DPS at depths 1, 5, and All; Hit DPS at depths 5 and All. With Fix Node Power giving nodes another node's score #10377, Introspection showed about 12,482 DPS instead of 905, and Low Tolerance showed 11,558 instead of zero.
• Both implementations were run against the same suite, including this PR’s regressions. This PR passed all 587 tests; Fix Node Power giving nodes another node's score #10377 had 585 passes and two failures covering mastery bonuses leaking into cluster notable results and modifiers added after initial parsing.

#10377 fixes the tested radius-jewel cases with less overhead, but this PR also addresses the remaining mastery/cluster and late-added-modifier cases. Its more selective cache sharing may be useful to reduce this PR’s overhead while retaining those fixes.

[PJacek]

Some of the performance difference could be caused by allocating a table for each node instead of building the key in-place.

[AdamZ-8113]

I tested building the key in place on two builds, and it didn't appear to be measurably faster. The label construction was virtually identical, the overall speed was ~2% slower which is probably just margin of error/smaller test sample.