拉取/合并请求描述：(PR description)

确保smp环境下 rt_thread_close 能真正关闭并停止目标线程的运行，可参考问题： #10554
[

为什么提交这份PR (why to submit this PR)

在SMP环境下，当一个运行在一个核心上的线程通过rt_thread_close和rt_thread_detach间接调用rt_thread_close试图关闭另一个核心上运行的线程时可能会存在潜在问题。具体而言，rt_thread_close的操作逻辑仅是将目标线程的控制块从调度队列中移除，并将其状态标记为关闭，但这一操作并不能立即终止目标线程的实际执行。

由于目标线程可能仍在另一个核心上运行，它无法实时感知到自身的关闭状态，只有下次触发调度时才会真正脱离CPU。这种延迟会导致关键问题：在rt_thread_close调用完成后，目标线程可能仍在执行代码，从而引发并发访问冲突或资源竞争等问题。

你的解决方案是什么 (what is your solution)

本pr的修改只会影响smp环境下的两条调用链：

rt_thread_delete -> _thread_detach -> rt_thread_close
rt_thread_detach -> _thread_detach -> rt_thread_close

不会影响线程通过 _thread_exit -> _thread_detach -> rt_thread_close 关闭自己的调用链

在rt_thread_close的实现中，当目标线程被标记为关闭状态后，如果其运行的核心与当前核心不同，系统会向其所在核心发送核间中断，以尽快触发该核心的重新调度，从而确保目标线程能够及时脱离 CPU 并真正停止执行。

而在 rt_thread_delete和 rt_thread_detach中，由于当前核心的调度已被 rt_enter_critical 禁用，因此采用轮询机制检测目标线程是否已完全脱离 CPU。为了应对目标核心始终无法调度的极端情况，设置了超时机制。该超时时间应该与硬件平台性能和系统负载相关，目前暂采RT_SMP_THREAD_DETACH_TIMEOUT宏进行配置。

请提供验证的bsp和config (provide the config and bsp)

• BSP:

• .config:

• action:

]

当前拉取/合并请求的状态 Intent for your PR

必须选择一项 Choose one (Mandatory):

• 本拉取/合并请求是一个草稿版本 This PR is for a code-review and is intended to get feedback
• 本拉取/合并请求是一个成熟版本 This PR is mature, and ready to be integrated into the repo

代码质量 Code Quality：

我在这个拉取/合并请求中已经考虑了 As part of this pull request, I've considered the following:

• 已经仔细查看过代码改动的对比 Already check the difference between PR and old code
• 代码风格正确，包括缩进空格，命名及其他风格 Style guide is adhered to, including spacing, naming and other styles
• 没有垃圾代码，代码尽量精简，不包含#if 0代码，不包含已经被注释了的代码 All redundant code is removed and cleaned up
• 所有变更均有原因及合理的，并且不会影响到其他软件组件代码或BSP All modifications are justified and not affect other components or BSP
• 对难懂代码均提供对应的注释 I've commented appropriately where code is tricky
• 代码是高质量的 Code in this PR is of high quality
• 已经使用formatting 等源码格式化工具确保格式符合RT-Thread代码规范 This PR complies with RT-Thread code specification
• 如果是新增bsp, 已经添加ci检查到.github/workflows/bsp_buildings.yml 详细请参考链接BSP自查