Feature idea: an admin-only category visibility tier for the Help Center (a 3rd tier beyond public/internal)

[iPLAYCAFE-dev]

Context. We run Quackback with the Help Center doubling as an internal team docs hub alongside the public KB. (Thanks for merging #325 — the inbound-email body fetch — much appreciated!)

The gap. Today an HC category is either public (isPublic = true) or internal (visible to all authenticated team members). There's no way to make a category readable by admins only — e.g. ops notes, review cadences, or non-sensitive product-decision logs that regular members shouldn't see. Authenticated reads currently resolve to both roles, so "internal" means "everyone on the team".

Proposal — a 3rd visibility tier via an additive admin_only boolean on categories:

• A mandatory DB CHECK (NOT (admin_only AND is_public)) — the two are mutually exclusive (a category can't be both admin-only and world-public).
• admin_only applies to the whole descendant subtree (computed app-side at read time), so a child under an admin-only parent is hidden too.
• A fail-closed includeAdminOnly read parameter (default false) wired from the verified role at every read surface (server-fn, REST, MCP), so a forgotten call site hides content rather than leaking it.
• Read-side defense-in-depth: the anonymous/public consumers also exclude the admin-only subtree, so a write-path regression can't surface admin-only content publicly.

Why a discussion first. It's an opinionated feature — a visibility/security boundary rather than a bugfix — so before investing in a polished PR we'd like to gauge interest and design preferences:

1. Is an admin-only category tier something you'd consider upstream?
2. If so, any preferences on the shape — column naming, whether the read gate belongs in the domain layer vs per-surface, how you'd want it tested?

We have a working implementation on our fork (built on top of #325) and are happy to open a PR adapting to your conventions + test style if there's appetite. Thanks!