Add manager-only permissions within department handbooks

Let each department handbook hold both general team SOPs and manager-only SOPs in one place, without splitting content across separate handbooks or external docs.
Restrict sensitive manager content so only leads and managers can read it, while the rest of the department still has a single handbook entry point.

Handbook access today is space-level, not article-level: users either have access to an entire handbook type or they do not.
Permissions are handbook, handbook-inspector, handbook-office, and handbook-admin in attik-backend/src/util/data/permissionsData.ts. Global roles such as leader and exec-leader exist but are not used to filter which help docs a user can read within a handbook.
Help docs are company-scoped (_companyId) with list set to help-docs or handbook. The schema in attik-backend/src/models/helpDocSchema.ts has no visibility, audience, or manager-only field.
The helpdoc list API in attik-backend/src/routes/helpdoc.ts filters by company, list, and status only—no role-based read filtering.
The handbook UI in attik-frontend/src/app/tools/handbook/[[...id]]/page.tsx gates routes with handbook-inspector vs handbook-office and uses handbook-admin for edit; anyone with handbook access for that space sees all active docs returned by the API.
This work is feature/enhancement work under the Company Handbook project (parent ATT-1725). It builds on having department handbook spaces (related work such as team-specific handbooks); manager-only visibility is an additional layer on top of those spaces.

Backend

Extend the help doc model (attik-backend/src/models/helpDocSchema.ts) with a way to mark content as manager-only (or equivalent audience metadata)—field name and shape are decision needed.
Enforce visibility on read in attik-backend/src/routes/helpdoc.ts (list and single-doc GET) so non-managers never receive restricted content, including search/aggregate paths if they apply to handbook docs.
Align with existing permission and role patterns in attik-backend/src/util/data/permissionsData.ts (e.g. whether leader / exec-leader, a new grant, or department-specific leads define “manager”).

Frontend

Handbook routes and listing in attik-frontend/src/app/tools/handbook/[[...id]]/ (page.tsx, HelpDocBase.tsx, HelpDocForm.tsx, HelpDocSheet.tsx) should respect restricted docs: authoring UI for managers to flag content, and read UI that hides or blocks restricted articles for unauthorized users.
Decision needed: Should restricted docs be omitted entirely from category/search lists for non-managers, or shown with a “no access” state?
Decision needed: Can managers edit manager-only docs only, or also general department docs? Is handbook-admin sufficient for authoring restricted content?

Out of scope (unless explicitly pulled in)

Cross-brand or LP-shared handbooks (company-scoped docs only today).
Replacing the existing office vs inspector handbook split; this adds within-space audience control.

Parent epic: ATT-1725 (Company Handbook)
Related: department / team handbook spaces (e.g. ATT-1712)
Backend entry points: attik-backend/src/models/helpDocSchema.ts, attik-backend/src/routes/helpdoc.ts, attik-backend/src/util/data/permissionsData.ts
Frontend entry points: attik-frontend/src/app/tools/handbook/[[...id]]/page.tsx, HelpDocBase.tsx, HelpDocForm.tsx

Attik