[BUG] — Logging send pools: `AbortPolicy` silently drops log-send tasks + `keepAliveTime=60000 MICROSECONDS` (60 ms, not 60 s) unit bug

- severity: Medium
- files: `shenyu-plugin/shenyu-plugin-logging/shenyu-plugin-logging-huawei-lts/.../HuaweiLtsLogCollectClient.java:176-178`, `.../aliyun-sls/.../AliyunSlsLogCollectClient.java:184-186`, `.../tencent-cls/.../TencentClsLogCollectClient.java:163-164`; constants `GenericLoggingConstant.java:43,48`
- description: All three cloud logging send pools are `new ThreadPoolExecutor(sendThreadCount, MAX_ALLOW_THREADS=500, 60000L, TimeUnit.MICROSECONDS, new LinkedBlockingQueue<>(MAX_QUEUE_NUMBER=10000), AbortPolicy)`. (a) `keepAliveTime = 60000 µs = 60 ms` — almost certainly intended 60 s; idle send threads are churned every 60 ms. (b) Once the 10000-slot queue + 500 threads saturate, `AbortPolicy` throws `RejectedExecutionException` per log-send → silent log loss with only a stacktrace; no caller backpressure.
- impact: High log volume → dropped logs + thread churn across the three cloud logging plugins.
- suggested_fix: `CallerRunsPolicy` (or bounded queue with block-on-full); fix the keepAlive unit to `SECONDS`/`MINUTES`; consider core==max.
- confidence: Medium-High

---
_Identified during the 2026-08-02 deep re-scan; full list in [`docs/scan2-2026-08-02/06-medium-tiers.md`](docs/scan2-2026-08-02/06-medium-tiers.md)._

Start with the ThreadPoolExecutor definitions in HuaweiLtsLogCollectClient.java:176-178, AliyunSlsLogCollectClient.java:184-186, and TencentClsLogCollectClient.java:163-164, then compare GenericLoggingConstant.java:43,48. Confirm the keep-alive unit and rejection behavior across all three pools; done means idle-thread timing is corrected and saturated pools no longer silently lose log-send tasks.

Written by the indexing model from the issue text.