Add an admin endpoint to toggle maintenance mode at runtime

[Jagadeeshftw]

📌 Description

src/middleware/maintenanceMode.ts exposes a maintenanceMode(enabled) middleware factory, but nothing in src/app.ts/src/routes currently lets an operator flip it without a redeploy. Add an authenticated toggle endpoint.

🧩 Requirements and context

• Add POST /api/v1/admin/maintenance accepting { enabled: boolean }, gated by the existing apiKeyAuth middleware.
• The toggle must update the same in-process flag maintenanceMode() reads, taking effect on the next request with no restart.
• Log the transition through middleware/auditLog.ts including the actor and timestamp.

🛠️ Suggested execution

• Wire a small in-memory mutable flag module read by maintenanceMode.ts and written by the new route.
• Add the route under src/routes/ (or extend src/app.ts if routes are kept flat) with apiKeyAuth applied.
• Add route tests asserting non-maintenance routes start returning 503 immediately after the toggle, and that unauthenticated toggle attempts are rejected.

✅ Acceptance criteria

• Toggling maintenance mode via the endpoint takes effect without a process restart.
• The endpoint requires a valid API key.
• Audit log records who toggled maintenance mode and when.

🔒 Security notes

Restrict the endpoint to the same API key used elsewhere; consider requiring a distinct admin-scoped key if the general API key is broadly distributed.

📋 Guidelines

• Minimum 95% test coverage
• Clear documentation
• Timeframe: 96 hours

[GBOYEE]

Hey, I'd like to help with this (Add an admin endpoint to toggle maintenance mode at runtime). I'll write the missing test coverage and wire it in. I'll get a PR up for this as soon as I'm assigned.

[Jagadeeshftw]

@GBOYEE thanks for the interest — you're currently at the 6 open-issue assignment cap for this repo, so I can't assign this one right now (backfill automation). Please finish or release one of your existing assigned issues, then request this one again and it'll be picked up.

[Jagadeeshftw]

@GBOYEE rechecked under today's corrected cap rule (an assigned issue only stops counting once some PR references it with a closing keyword). none of your 6 currently assigned issues (#101, #100, #88, #87, #80, #78) have a PR up yet, so all 6 still count and you're still right at the 6-issue cap — sorry, still can't assign this one or the others.

separately: you now have 12 open requests sitting across this repo (#74, #77, #81, #82, #83, #84, #85, #92, #94, #96, #97, #99) with zero PRs opened against your existing 6 assignments in between. please stop applying to new issues for now and finish/open PRs for a few of what you already have — once one of those six gets a PR up (even a draft), it'll drop off your cap count and you'll have room again.

[grantfox-oss]

🦊 GrantFox — @GBOYEE has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #74)
2. Your PR will be reviewed by the AnchorNet-Org maintainers

Good luck! Track your progress on GrantFox.