docs: sync v6.2.5

[wisdommen]

UltiTools-API v6.2.5 已发布，文档需要同步。

• examples/pom.xml 的 <ultitools.version> 更新为 6.2.5
• .vitepress/config.mts 的 versionsConfig.current 更新为 v6.2.5，并把 docs/src/ 快照进 docs/archive/
• mvn -f examples/pom.xml compile 通过（编译失败的示例即需要改的页面）
• 跑 ./scripts/report-doc-coverage.sh 6.2.4 6.2.5（第一个参数替换为上一个正式发布版本号，示例中的 6.2.4 仅供参考）并处理报告中的两段清单

关闭本 issue 即代表本次同步完成。

[wisdommen]

Content defect found while auditing the AOP wiring upstream

Not one of the four mechanical steps above, but it falls inside this sync window because it
describes behaviour that is already wrong for the released 6.2.5, not something 6.3.0 introduces.

Location (identical line in both locales):

• docs/src/guide/advanced/exception-handling.md:116 — "Any class registered manually in the IoC container"
• docs/src/zh/guide/advanced/exception-handling.md:116 — 「任何手动注册到 IoC 容器中的类」

Both appear under the "Supported bean types" list, alongside @Service and @Component.

Why it is wrong. AOP uses inheritance-based subclass proxies, so the proxy has to be generated
at construction time. SimpleContainer.registerSingleton(String, Object) and
registerType(Class, T) both receive an already-constructed instance, so there is no opportunity
left to construct it as a subclass. AopProxyResolver.resolve() runs only on the constructor
branch of bean creation, which means manually registered objects never reach it. The annotation is
silently inert: no error, no warning, no interception.

What is actually affected: the plugin main class itself, @ConfigEntity configuration objects,
@ContextEntry beans, @Configuration classes and everything their @Bean methods produce, plus
any instance an author hands to the container through registerSingleton / registerType.

Suggested replacement rule, in a form an author can apply without knowing the container's
internals: objects the framework constructs for you get a proxy; objects you construct yourself and
then hand to the container do not.

Related page. docs/src/guide/advanced/ioc-container.md teaches manual registration via
registerType() without noting that AOP does not apply there. The two pages together lead an author
straight into the gap: one shows how to register manually, the other says manually registered
classes are supported.

transactions.md needs no change on this point — it already scopes @Transactional to @Service
beans in both locales.

---

在为上游 AOP 接线做审计时发现的内容缺陷。 不属于上面四条机械步骤，但它描述的是已发布的 6.2.5
就已经错误的行为，而非 6.3.0 新引入的内容，因此落在本次同步窗口内。

问题出在两个 locale 的同一行（exception-handling.md:116），它把「手动注册到 IoC 容器中的类」
列为支持 AOP 的 Bean 类型。实际上 AOP 走的是继承式子类代理，代理必须在构造时生成；
registerSingleton 与 registerType 收到的都是已经构造好的实例，没有再生成子类的机会，
AopProxyResolver.resolve() 只在 bean 创建的构造分支上运行。注解因此完全静默失效。

受影响的包括插件主类、@ConfigEntity 配置类、@ContextEntry、@Configuration 与 @Bean 产出的对象，
以及作者手动放进容器的任何实例。建议的准确表述：框架替你构造的对象才有代理，你自己 new 好再交给容器的没有。

ioc-container.md 的手动注册章节教的正是 registerType()，两页合起来会把作者引向这个缺口。
transactions.md 在这一点上无需改动，它本来就把 @Transactional 限定在 @Service Bean 内。