[功能建议] 默认开启 CONFIG_KERNEL_DYNAMIC_FTRACE，使 dae 等 eBPF 工具原生 fentry 生效

ImmortalWrt 25.12.1 已为 eBPF 生态开了 KERNEL_FTRACE / KERNEL_KPROBES / KERNEL_DEBUG_INFO_BTF / KERNEL_NETKIT，但缺关键的 KERNEL_DYNAMIC_FTRACE。

问题 dae（及 sing-box/xray 等）的 TCP relay eBPF offload 通过 fentry 挂到 skb_send_sock_locked 实现内核快路径转发；fentry 需 DYNAMIC_FTRACE 才能在内核函数入口干净 poke NOP 桩（bpf_arch_text_poke）。内核缺此项时 fentry attach 直接 EBUSY，只能回退 kprobe（上游 olicesx/dae 的 353e9526 即此 workaround）。

实测（ImmortalWrt 25.12.1 x86_64, kernel 6.12.94）：

• cat /sys/kernel/debug/tracing/available_tracers 仅返回 nop（无 function/function_graph）；
• dae 日志：TCP relay eBPF offload fentry accounting unavailable; falling back to kprobe (EBUSY) → 随即 TCP relay eBPF offload enabled (sk_skb stream verdict on fast_sock)；
• 根因确为内核缺 CONFIG_DYNAMIC_FTRACE（kallsyms 无 mcount 桩）。

建议：所有架构默认开启 CONFIG_KERNEL_DYNAMIC_FTRACE=y（x86_64/aarch64 收益最直接，对不支持 fentry 的架构亦无副作用）。

收益：① dae/sing-box/xray 的 offload 用上原生 fentry（比 kprobe 断点更省每包开销、更干净）；② 内核自带完整 ftrace（function/function_graph），便于调试 eBPF 及其它内核问题。

成本（极低）：禁用 tracing 时每函数约 1 cycle 开销（默认 tracing 关闭即零运行时开销）；内核体积微增（数十~数百 KB）。

兼容性：官方统一构建，内核 vermagic 与官方 kmod 源同源一致，不会像用户自编译改内核那样导致 apk 安装 kmod ABI 不匹配，反而扩大 eBPF 类工具可用面。

范围建议：优先 x86_64 + aarch64；若评估无副作用建议全局默认开启。请维护者定夺。另建议同步 OpenWrt 上游默认开启。