This PR addresses multiple correctness and hardening issues in WinFormedge’s WebResource and WebView initialization paths. It fixes incorrect handler resolution/unregistration behavior, makes WebView initialization failures observable, tightens default security posture, and aligns README API examples with the current public entrypoint.

• WebResource routing correctness

  • Changed handler selection to prefer the most specific path prefix (longest AbsolutePath) instead of the least specific one.
  • Prevents broad handlers from shadowing narrower handlers (e.g. /api/ vs /api/v1/).

• WebResource unregister correctness

  • Unregister now removes all matching handlers by scheme/host (case-insensitive).
  • Filter removal now uses each handler’s original WebResourceContext instead of hardcoded All, preventing stale filters.

• WebView initialization failure handling

  • Replaced CreateWebView2 async void flow with CreateWebView2Async (Task) and awaited it from handle creation.
  • Captures initialization exceptions and routes them to Startup.OnApplicationException(...).
  • Controller access now throws a descriptive InvalidOperationException with captured initialization exception context.

• Security baseline hardening

  • Enabled tracking prevention by default in CoreWebView2EnvironmentOptions.
  • Enabled reputation checking by default in CoreWebView2Settings.
  • Stopped returning raw exception messages in HTTP 500 responses for web resources.

• Documentation/API alignment

  • Updated README examples to use WinFormedgeApp.CreateAppBuilder() and consistent WinFormedgeApp naming instead of outdated FormedgeApp.CreateBuilder() references.

// Before
var targetHandler = matchedHandlers.OrderBy(x => x.Uri.AbsolutePath.Length).FirstOrDefault();

// After
var targetHandler = matchedHandlers.OrderByDescending(x => x.Uri.AbsolutePath.Length).FirstOrDefault();