GHSA-7rx3-5wx3-5v76

### Summary Non-admin operators (role `user`) can set `allow_private: true` on their own managed webhook subscription (`POST`/`PATCH /api/v1/webhook-subscriptions`). No admin check exists on this field. At delivery time, `allow_private` switches the dispatcher to an unguarded HTTP client, bypassing the private/loopback/link-local SSRF guard — letting a low-privilege operator make the server request internal addresses. ### Details `internal/api/webhooks.go:67` (`handleCreateWebhookSubscription`) and `:110` (`handleUpdateWebhookSubscription`) persist operator-supplied `AllowPrivate` with no role check — only ownership is enforced (`canAccessWebhookSub`), and that's not even called on create. `internal/webhook/webhook.go:294-296`: ```go client := d.guarded if tgt.AllowPrivate { client = d.unguarded } ``` `d.unguarded` skips the loopback/private/link-local rejection `config.ValidateWebhookURL` otherwise enforces. Every other tenant-impacting toggle (network create `internal/api/networks.go:21`, settings PATCH `internal/api/settings.go:36`, CA management) gates on `isActiveAdmin`. `allow_private` is the exception — introduced with managed webhook subscriptions (PR #258) and missed by the two prior fixes for the same authz-gap class in this repo (GHSA-598g-h2vc-h5vg, GHSA-c6v2-3ffm-vcmc). ### PoC Verified live against a real running instance of nebula-mesh (HEAD `2c3457c`, built and run locally, no third-party requests made — the "internal service" below is a loopback listener standing in for one). Setup: `nebula-mgmt init` + `serve` on `127.0.0.1:8181`; admin CLI creates operator `lowpriv` with `-role user` and mints it an API key (`d984bb...c7c`) — the routine, legitimate way any non-admin operator gets access. `lowpriv` self-mints its own CA (`POST /api/v1/cas`, allowed for any operator) and creates a host on a network scoped to that CA, so it owns something it can legitimately act on. **Step 1 — create-side bypass, as the non-admin `lowpriv` operator:** `