refactor(channel-monitor): event-driven scheduler + sidebar cleanup

后端 - ChannelMonitorRunner 重写为事件驱动调度
- 删除 5 秒轮询架构（每次 ListEnabled + listDueForCheck 全表扫描），
  改为每个 enabled monitor 一个独立 goroutine + ticker（按各自 IntervalSeconds）
- 新增 MonitorScheduler 接口，service 通过 setter 注入避免依赖环
- ChannelMonitorService.Create/Update/Delete 直接回调 scheduler.Schedule/Unschedule
- runner.Start 一次性加载所有 enabled monitor 建立任务表
- 新建/启用立即触发首次检测，禁用/删除即时撤销 ticker
- 保留 inFlight 去重 + pond 池并发上限 + 全局开关每次 fire 实时校验
- 删除 listDueForCheck / monitorTickerInterval / monitorListDueTimeout

前端 - 可用渠道改为用户级菜单
- 从 adminNavItems 移除 /available-channels（admin 主菜单不再重复出现）
- buildSelfNavItems 始终包含可用渠道入口，普通用户主菜单和
  管理员"我的账户"区都能看到

backend/internal/service/channel_monitor_const.go

@@ -28,8 +28,8 @@ const (
 	monitorMaintenanceMaxDaysPerRun = 35
 	// monitorWorkerConcurrency 调度器并发执行的监控数（pond 池容量）。
 	monitorWorkerConcurrency = 5
-	// monitorTickerInterval 调度器扫描"到期监控"的间隔。
-	monitorTickerInterval = 5 * time.Second
+	// monitorStartupLoadTimeout Start 时一次性加载所有 enabled monitor 的总超时。
+	monitorStartupLoadTimeout = 10 * time.Second
 	// monitorMinIntervalSeconds / monitorMaxIntervalSeconds 用户配置的检测间隔上下限。
 	monitorMinIntervalSeconds = 15
 	monitorMaxIntervalSeconds = 3600
@@ -86,8 +86,6 @@ const (
 	// monitorChallengeMaxTokens 单次 challenge 请求的 max_tokens（足够回答个位数算术）。
 	monitorChallengeMaxTokens = 50
 
-	// monitorListDueTimeout tickDueChecks 查询到期监控的总超时。
-	monitorListDueTimeout = 10 * time.Second
 	// monitorRunOneBuffer runOne 的总超时缓冲（除请求超时与 ping 超时外的额外裕量）。
 	monitorRunOneBuffer = 10 * time.Second