docs(admincom): add AdminCom userscripts guide

[netravnen]

Add a documentation guide covering the three Tampermonkey userscripts AdminCom relies on for day-to-day moderation (Control Panel, public frontend, and DeskPro), grounded directly in the current source rather than the stale internal README. Screenshot placement is marked inline so reviewers can capture and add images before this is merged.

Changes:

• docs/committee/admin/userscripts/index.md: install steps and shared concepts (module disable list, feature flags, debug mode)
• docs/committee/admin/userscripts/cp.md: full Control Panel guide covering all 27 modules, menu commands, and configuration
• docs/committee/admin/userscripts/fp.md: full frontend guide covering all 10 modules, menu commands, and configuration
• docs/committee/admin/userscripts/deskpro.md: ticket enrichment, Whitelist CMD Generator, and IXLAN Renumber launcher
• docs/committee/admin/index.md: link to the new guide

Security:

• Documentation only, no code or access changes
• Publishes internal tooling detail (including the destructive netixlan renumber/conflict-resolver tools) to a public docs site; flagged for maintainer review before merge given the operational detail involved

Testing:

• No local mkdocs/uv install available to run a full site build
• Manually verified markdown structure (admonition indentation, link syntax) with a script pass over the new files

Backwards Compatibility:

• Additive only; no existing pages, nav entries, or links were changed besides the new "AdminCom Userscripts" link on the admin index page

[ccaputo]

Since these are internal tools, shouldn't they be documented internally rather than publicly? docs.peeringdb.com is not intended to be a wiki for internal use.

[ccaputo]

I could be totally wrong about this. But my fear is that a hybrid documentation site for public and internal use, will inevitably end up aiding compromise at some point. IMHO, better to not go down that path.

[grizz]

I tend to agree that keeping it off the public site is better, but mostly for not confusing users. :)

@netravnen What are your thoughts on creating an AC private repo?

cc @peeringdb/ac

[cappaxyz]

Private repo is probably wiser; or do we just set the peeringdb/ac github repo to only visible to PeeringDB org members, and track our internal documentation and snippet changes there?