feat(plugins): 访问控制在插件页配置 + 修复 active 仪表在周期视图显示 0

## 插件管理页（用户要求：权限不要只放 config.yaml）

插件页新增两列（可见性、端点）和一块访问控制编辑器，可直接改：
- 每个插件的整体可见性（跟随插件 / 仅 admin / 仅 user / admin+user / 所有人）
- 每个注册端点的可访问角色与密钥（admin, user, @homeagent, public）

原先这些能力后端齐全但 WebUI 零入口，唯一改法是手改 config.yaml。

## 修掉的三个真缺陷

1. endpointAccess 读错了 override 的键
   SetEndpointAccess 按 plugin#path 存，endpointAccess 却读 plugin 级。
   后果：改了权限后 UI 仍显示插件声明的角色，再保存一次就把限制悄悄撤销。
   鉴权一直是对的，只有显示和往返是坏的 —— 所以之前没被发现。

2. override 只在内存里
   内存 map 让"billing 仅 admin"看着生效，直到下次重启限制凭空消失，
   日志里没有任何线索。现在落盘到 plugin_dir/.access.json，
   插件升级覆盖 .state.json 也不会连带放宽访问。删掉最后一个 override 就删文件，
   "没有覆盖"用文件不存在来诚实表达。

3. 可见性列表泄漏内部键
   端点 override 与插件可见性共用一个 map，UI 因此会看到 "probe#hello"
   并可能把它当 audience 存回去。现在按已注册端点集合过滤。

另外把整体可见性接到同一条 /access 通路（path 用 *），并修了可见性下拉的
集合比较：服务端原样存 "admin, user"，而选项是 "user,admin"，不相等就会
显示"跟随插件"，用户一保存就把访问范围放宽回插件声明 —— 比显示错更糟。

## 活跃请求：三个视图显示 0

active 是实时仪表，没有日历周期可过滤，但周期响应压根没带这个字段。
前端 `st.active || 0` 于是把"字段缺失"变成了一句自信的"0 活跃"，
而 all 视图（响应里有该字段）显示真值 —— 三个视图 0、总视图正常。
现在周期响应带上 active，前端去掉 || 0 回退：缺失显示 — 而不是假装是 0。

判据：四个 period 都断言 active 存在且为数字；变异去掉字段即变红。
生产实测 day/week/month/all 均为 4。

Co-Authored-By: ModelRouter <noreply@modelrouter.dev>

internal/gateway/plugins_api.go

@@ -130,6 +130,11 @@ func (g *Gateway) handlePluginsAPI(w http.ResponseWriter, r *http.Request) {
 				"on_disk":     ps.OnDisk(),
 				"hook_errors": ps.HookErrors(),
 				"plugin_dir":  g.pluginDir(),
+				// Visibility overrides and the endpoint access table, so the
+				// plugin page renders what is IN FORCE rather than making the
+				// operator read .lua files or config.yaml to find out.
+				"visibility":   ps.VisibilityOverrides(),
+				"http_access": ps.EndpointAccess(),
 			})
 		case http.MethodPost:
 			var body struct {
@@ -388,6 +393,17 @@ func (g *Gateway) handleEndpointAccess(w http.ResponseWriter, r *http.Request, n
 	}
 	ps := g.core.Plugins()
 
+	// epPath "*" is the WHOLE-PLUGIN visibility override, not an endpoint. It
+	// shares this route (and therefore this store) on purpose: an operator
+	// setting "who can see this plugin" and "who can call this endpoint" is
+	// asking the same question at two granularities, and two stores would let
+	// them disagree. SetEndpointAccess cannot serve it — it validates that the
+	// endpoint exists, which "*" by definition does not.
+	if epPath == pluginWholeOverride {
+		g.handlePluginVisibility(w, r, name)
+		return
+	}
+
 	switch r.Method {
 	case http.MethodGet:
 		for _, e := range ps.EndpointAccess() {
@@ -489,3 +505,41 @@ func filterKeyBuckets(v interface{}, masked string, depth int) interface{} {
 		return out
 	}
 }
+
+// pluginWholeOverride is the epPath that addresses a plugin's overall visibility
+// rather than one of its endpoints.
+const pluginWholeOverride = "*"
+
+// handlePluginVisibility is the whole-plugin half of the access API. The
+// audience string uses the same vocabulary as an endpoint spec (roles, @key
+// names, public) so the UI can drive both from one input.
+func (g *Gateway) handlePluginVisibility(w http.ResponseWriter, r *http.Request, name string) {
+	ps := g.core.Plugins()
+	switch r.Method {
+	case http.MethodGet:
+		writeJSON(w, http.StatusOK, map[string]interface{}{
+			"plugin":     name,
+			"visibility": ps.VisibilityOverrides()[name],
+		})
+	case http.MethodPut, http.MethodDelete:
+		spec := ""
+		if r.Method == http.MethodPut {
+			var body struct {
+				Access string `json:"access"`
+			}
+			if err := json.NewDecoder(r.Body).Decode(&body); err != nil {
+				writeError(w, http.StatusBadRequest, "invalid_request", "invalid json: "+err.Error())
+				return
+			}
+			spec = body.Access
+		}
+		if err := ps.ValidateAccessSpec(spec); err != nil {
+			writeError(w, http.StatusBadRequest, "invalid_request", err.Error())
+			return
+		}
+		ps.SetPluginVisibility(name, spec)
+		writeJSON(w, http.StatusOK, map[string]interface{}{"ok": true, "visibility": spec})
+	default:
+		writeError(w, http.StatusMethodNotAllowed, "method_not_allowed", r.Method+" is not allowed here")
+	}
+}