Add manager-only permissions within department handbooks

Objective

• 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.

Background

• 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.

Scope

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.

References

• 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