TC321X Master角色LE Secure Connections配对失败，secure_conn始终为0

GS7712

背景
角色：Central/Master
基础代码：官方demo vendor/ble_feature_test/feature_privacy_master，移植到TC321X

使用的SMP配置
blc_smp_setSecurityLevel(LE_Security_Mode_1_Level_2);
blc_smp_enableSecureConnections(1);
blc_smp_setSecurityParameters(Non_Bondable_Mode, 0, 0, 0, IO_CAPABILITY_NO_INPUT_NO_OUTPUT);
blc_smp_setEcdhDebugMode(non_debug_mode);
blc_smp_central_init();
blm_host_smp_setSecurityTrigger(MASTER_TRIGGER_SMP_FIRST_PAIRING);

现象
配对每次都失败。GAP_EVT_SMP_PAIRING_BEGIN 报告 secure_conn=0（Legacy），尽管已明确启用SC。之后协议栈发送的是 Pairing Confirm（SMP code 0x03，属于Legacy流程），而不是SC流程中应有的 Public Key（0x0C）。对端（用Zephyr/nRF设备测试）因协议序列错误而拒绝连接。

收集到的证据（在 blm_host.c 中加入自定义instrumentation，在协议栈处理之前直接dump原始字节）
- 发送的 Pairing Request：auth_req 中确实包含SC bit（对端日志和我们自己的log都确认了这一点）
- 收到的 Pairing Response：03 00 08 10 00 00 → auth_req=0x08 → 对端也提出了SC
- 也就是说，双方都正确提出了SC，交换的字节在两边都是正确的——但协议栈还是决定走Legacy流程

重要对比点
在同一颗芯片/同一个库上，几乎相同的SC配置，在Peripheral角色下完全正常工作（blc_smp_peripheral_init()），包括官方demo feature_smp_security。问题看起来是Master角色特有的。

问题
在这个SDK里，Master角色下的SC配对是一个经过验证/测试过的路径吗？是否有一个未在文档中说明的、Master角色特有的步骤或调用是必须的？