fix: unbreak the Debug build of the Blazor demo (fixes CodeQL on dev)

[phmatray]

The reported symptom was misleading

CodeQL reported:

We were unable to automatically build your code. Please change the build mode for this language to manual and specify build steps for your project.

That is autobuild's generic message, and it sent us toward reconfiguring code scanning. The actual cause is a real build break in this repository:

Microsoft.NET.Sdk.WebAssembly.Browser.targets(395,5): error : System.ArgumentException:
An item with the same key has already been added.
Key: .../bin/Debug/net10.0/wwwroot/_framework/Microsoft.DotNet.HotReload.WebAssembly.Browser.<hash>.wasm
   at Microsoft.NET.Sdk.WebAssembly.GenerateWasmBootJson.WriteBootConfig

No CodeQL configuration change is needed. Default setup is fine.

Why it hid for so long

Demo.BlazorWasm referenced Microsoft.DotNet.HotReload.WebAssembly.Browser explicitly, and the Blazor WebAssembly SDK already injects that package itself for Debug builds. The asset gets contributed twice and GenerateWasmBootJson throws on the duplicate key.

Release builds never inject the hot-reload asset — so:

	Debug	Release
Demo.BlazorWasm	failed	passed
CI/CD workflow	not run	✅ green
CodeQL autobuild	❌ fails here	not run

CI builds --configuration Release and stayed green throughout. CodeQL's autobuild builds Debug. That is the entire discrepancy, and it is also why dev shows a red CodeQL run while every CI run is green.

The fix

Drop the explicit PackageReference (and the now-unreferenced PackageVersion), leaving the SDK to supply and version the package — which is what it does for every other Blazor WebAssembly app. Hot reload under dotnet watch is unaffected.

Two lines removed.

Verification

Reproduced locally first (identical ArgumentException on the same MSBuild target), then confirmed fixed in both configurations:

dotnet build TaLibStandard.sln -c Debug    ->  Build succeeded, 0 Error(s)   (previously failed)
dotnet build TaLibStandard.sln -c Release  ->  Build succeeded, 0 Error(s)   (unchanged)

Worth noting the gap this exposes: CI only ever builds Release, so a Debug-only break reaches the default branch unnoticed. Adding a Debug leg to the CI matrix would have caught this — happy to do that separately if you want it.

🤖 Generated with Claude Code

[phmatray]

Force-pushed a corrected branch. The previous push was wrong: I ran git add -A after a local build, and DefaultDocumentation had regenerated 175 files under docs/candles/ and docs/functions/ with a different character encoding (🡒 → →). Those got swept into the commit, so the PR contained 177 files while this description claimed two.

The branch is now rebuilt from current dev with only the two intended edits, committed path-scoped. Rebuilt rather than rebased, because it also needed the conflict with #103's Renovate bump of that same HotReload line resolved in favour of deleting it.

Re-verified on the new base (which now includes #105):

dotnet build TaLibStandard.sln -c Debug    ->  Build succeeded, 0 Error(s)
dotnet build TaLibStandard.sln -c Release  ->  Build succeeded, 0 Error(s)

Separately worth knowing: any local build dirties those 175 generated doc files on a machine whose encoding differs from whoever last committed them. That is a trap for every contributor, not just this PR. Worth either gitignoring the generated output, generating it only in CI, or pinning the encoding — happy to open a separate issue.