fix: skip patch types that have no definition instead of throwing

[divya0795]

Fixes #172

Defensive hardening, not a live bug fix. As set out in the issue, this crash path is currently unreachable — no UI exposes DisableTelemetry and PatchConfig is never deserialised. I have no reproduction to offer, and I'd rather say so up front than dress this up as something it isn't. Close it if you'd prefer not to carry the guard.

Problem

EnhancerConfig.GetInstance() has entries for four of the five EPatchType members; DisableTelemetry = 4 has none. Both consumers indexed the dictionary directly:

var entries = enhancerConfig[entry];                    // Enhancer.cs:153
foreach (var patchEntry in enhancerConfig[patchType])   // Enhancer.cs:192

A PatchTypes set containing DisableTelemetry would abort the entire run with an unhandled KeyNotFoundException, discarding the other requested patches — and doing so after backups have been made and app.asar extracted.

Change

TryGetValue at both sites, skipping any type with no definition.

The skipped type is deliberately left in remainingPatches, so rather than being silently dropped it falls through to the existing end-of-run summary:

[ENHANCER] Failed to apply patches: DisableTelemetry. The version may not be supported.

That is the same channel an unmatched patch already reports through. PatchAsar additionally logs [ENHANCER] No patch definition for {entry}, skipping at ELogType.Warn.

I considered instead adding an empty DisableTelemetry entry to EnhancerConfig. That also stops the crash, but it makes a requested patch report success while doing nothing — worse than a clear failure.

Behaviour for all four implemented patch types is unchanged: they still resolve, apply, and clear from remainingPatches exactly as before. One file, +17 / -2.

Verification

No local Visual Studio/MSBuild environment, so this is not compile-verified locally. Compile evidence comes from dispatching this repo's own .github/workflows/build.yml (full build.ps1 → MSBuild, windows-latest) on my fork; run linked in a comment below.

There is no C# test project in the repo, and no licensed WeMod install here, so CONTRIBUTING.md's manual-testing step is not satisfied. Given the guarded path cannot currently be entered, the meaningful check is that the four live patch types are unaffected — which is what the build plus your normal patch run would confirm.

[divya0795]

Compile verification: dispatched this repo's own build.yml against this branch on my fork. It runs the full build.ps1 - pnpm install, web-panel build, NuGet restore, then MSBuild of Wand-Enhancer.sln on windows-latest.

Result: success in ~1.7 min

https://github.com/divya0795/Wand-Enhancer/actions/runs/30205236146

That satisfies "your code compiles without errors" from CONTRIBUTING.md. The manual-testing-against-WeMod step remains outstanding on my side, as flagged in the PR description.