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

从 LoggingAdmin.getInstance() API 以及所引用的 Tomcat ContextBindings.bindContext 行为开始。该 issue 未指定文件或测试；当明确约定并记录 token、classloader 作用域，以及共享 context 与隔离 context 的行为，并确定实现范围后，工作即告完成。

由索引模型根据 Issue 内容生成。