Specify behavior of `LoggingAdmin.getInstance()`

The current design of `LoggingAdmin.getInstance()` requires a token, conceptually similar to Tomcat’s [`ContextBindings.bindContext`](https://tomcat.apache.org/tomcat-9.0-doc/api/org/apache/naming/ContextBindings.html#bindContext(java.lang.Object,javax.naming.Context,java.lang.Object)). This token mechanism was introduced to prevent libraries from unintentionally overriding an application’s logging configuration.

### Limitations of the Current Approach

This token-based protection is inherently **opt-in**, which makes it unreliable. Libraries can—and often do—interact directly with the underlying logging framework (e.g., Logback, Log4j2). As a result, the intended protection is easily circumvented, especially in environments where multiple applications or libraries share a common logging context.

### Proposed Direction

To create a more effective and resilient mechanism, we should consider shifting away from opt-in tokens toward a **cooperative, classloader-aware model**. For example, the logging system could expose metadata indicating whether the logger context is scoped:

* **Per web application** (isolated)
* **Globally** (shared across apps)

This information would enable frameworks like Spring Boot to detect shared contexts and conditionally **disable logging auto-configuration** to avoid overriding the shared settings.

### Goals

* Eliminate reliance on opt-in tokens for logging protection
* Support classloader-aware logging context scoping
* Enable frameworks to behave appropriately in shared vs. isolated environments

Start with the LoggingAdmin.getInstance() API and the referenced Tomcat ContextBindings.bindContext behavior. The issue names no files or tests; work is complete when the token, classloader-scoping, and shared-versus-isolated-context behavior are explicitly agreed and documented, with implementation scope identified.

Written by the indexing model from the issue text.