Treat JVM platform frames (java.*, kotlin.*, ...) as non-user code in error stacking #2679

Problem

ErrorSignature decides which stack frame is "user code" by namespace. With no User Namespaces configured, every namespace except System and Microsoft counts as user code:

• ErrorSignature.cs#L13: _defaultNonUserNamespaces = ["System", "Microsoft"]
• ErrorSignature.cs#L182-L191: IsUserNamespace

For Java (and Kotlin, Scala, ...) errors, the JDK frame that threw becomes the stacking target. For example, Integer.parseInt("two") stacks on:

ExceptionType: java.lang.NumberFormatException
Method:        java.lang.NumberFormatException.forInputString(...)

So every NumberFormatException from Integer.parseInt in a project lands in one stack, no matter which application method called it. The same happens for Objects.requireNonNull, collections, I/O and so on. The new Java client's end-to-end tests reproduce this against 8.10.0 (StackingSignatureE2ETest). Two unrelated call sites get the same stack_id.

Proposal

Add the JVM platform namespaces to the default non-user list:

java, javax, jdk, sun, com.sun, jakarta, kotlin, kotlinx, scala

Also match on a namespace boundary (ns == prefix || ns.StartsWith(prefix + ".")) instead of a bare StartsWith. Otherwise sun would also match a user namespace like sunrise.billing; today System already matches SystemsIntegration.*.

To discuss: whether common frameworks (org.springframework, org.apache, org.hibernate, io.netty, reactor, com.fasterxml) should also be non-user by default. .NET already treats all of Microsoft.*, including ASP.NET Core and EF Core, as non-user, so including them would be consistent.

Notes

• If no user frame is found, the existing fallback still uses the innermost error's top frame, so pure-JDK traces keep a signature.
• Signature hashes change for existing Java/Kotlin stacks, so their next occurrence creates a new stack. The old Java client (0.1) couldn't send stack traces in the format the server reads anyway, so few existing stacks are affected.
• Projects can already get this behaviour by setting User Namespaces, but that setting doesn't work from the UI today (see User Namespaces and Common Methods project settings have no effect on stacking #2678).

Context: exceptionless/Exceptionless.Java#91, exceptionless/Exceptionless.Java#92