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

Bắt đầu với API LoggingAdmin.getInstance() và hành vi ContextBindings.bindContext của Tomcat được đề cập. Issue không nêu tên tệp hay test nào; công việc được hoàn tất khi token, phạm vi của classloader và hành vi của context dùng chung so với context cô lập được thống nhất và ghi lại một cách rõ ràng, đồng thời phạm vi triển khai được xác định.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.