Do not throw on breakpoint event for a replaced breakpoint

[nevse]

SetBreakpoints deactivates the old ICorDebugFunctionBreakpoints and drops the BreakpointInfos that own them. A hit that was already in flight then finds nothing:

var managedBreakpoint = _breakpointManager.FindByCorBreakpoint(functionBreakpoint);
ArgumentNullException.ThrowIfNull(managedBreakpoint);

Activate(false) cannot cancel a hit that has already happened — the process is frozen and the event is queued. The runtime callback does not take DapRequestAndRuntimeEventLock either, so draining the queue at the start of each request narrows the window without closing it: the event can land after the drain and before the replace.

Every other "not our case" branch in that method logs and continues, including the one for an unrecognised breakpoint type a few lines above. This does the same.

Re-sending one file's breakpoints every 20ms for 15s while the debuggee hits them, over SharpDbgInMemory:

	throws	hits handled as replaced
66db871	3–4	—
with this	0	1–6

It is not a freeze on current main — the failed-handler recovery catches the throw and continues the process, so the session survives. What is left is an ordinary race being reported as an unexpected failure and relying on a last-resort path: that recovery only continues if TryIsRunning returns S_OK, and it calls Continue() rather than ContinueWithVariableClear() like the rest of the method. On 0.1.9, before the recovery existed, the same hit froze the debuggee for good.

No test: reproducing it needs the 20ms churn above, and a test built on that timing would be flaky. Happy to add one if you can see a deterministic way in.

Rebased onto 534170d, SharpDbg.Cli.Tests 32 of 32.

(This PR originally also made _modules a ConcurrentDictionary. Dropped — that could not be reproduced on 0.1.12, see the comments.)

I agree to the terms of contributing as stated here

[MattParkerDev]

Regarding the decompiles test - I bumped the decompiler version which changed the output file - clear your SharpIdeSymbolsCache, that should fix it. Added a comment at the failing assertion, because I noticed this too.

[MattParkerDev]

@nevse The managed breakpoint change looks good.

Regarding the dictionary change - I'm not convinced this is necessary - the dap request and event processing lock is intended to fix the error you are reporting. 0.1.9, the version you reproduced it on, was before this locking was introduced. Please reproduce this on main/0.1.12

Also, is your MCP server no longer open source?

[nevse]

That was it — cleared the cache and the suite is 32 of 32. My diagnosis in the description was wrong, sorry: it was stale decompiler output on my side, not anything of yours.

[nevse]

You're right — dropped it. I hammered setFunctionBreakpoints while the debuggee loaded ~46 assemblies, 100k+ requests a run: 0.1.9 threw it once in six runs, 0.1.12 never in five. Thin either way, but nothing to show on 0.1.12, and your reasoning about the lock holds.

And yes, it's open source — https://github.com/nevse/SharpDbg.MCP. I just haven't pushed since the start of the month, so none of what I've been quoting is up there yet.

[MattParkerDev]

@nevse please restore the footnote in the PR description, from the PR template

[nevse]

Restored, and in #34 as well - I had dropped it in both.