fix(server): remove auth from proceed-db-migration endpoint

[jbsmith7741]

Summary

Removes auth.RequireAuth() middleware from the /proceed-db-migration endpoint. When AUTH_ENABLED=true, auth tables (e.g. auth_sessions) may not exist yet if the pending migration is the one that creates them — resulting in a bootstrap deadlock where the migration endpoint requires auth but auth requires the migration to have run.

This restores the pre-auth-hardening behavior for this endpoint, which is idempotent and only executes pending migration scripts.

Does this close any open issues?

N/A

Other Information

• The endpoint remains idempotent (only runs pending migrations) and is typically accessed via the config-ui proxy, not exposed publicly.
• Config-ui's "Proceed" button already calls this endpoint without authentication handling.
• This unblocks any PR that adds new migration scripts (e.g. Jira plugin schema changes) from failing on auth-enabled deployments.

[klesh]

Can we go a different route based on whether the table exists?

[jbsmith7741]

We could do a check that the table exists on every migration request, but that would add unnecessary overhead and make the process more fragile. I've added the route as a public path, as the migrations endpoint is idempotent and only triggers pending migrations—there is very little risk associated with this being public, and it resolves the issue in a clean manner.

[klesh]

We could do a check that the table exists on every migration request, but that would add unnecessary overhead and make the process more fragile. I've added the route as a public path, as the migrations endpoint is idempotent and only triggers pending migrations—there is very little risk associated with this being public, and it resolves the issue in a clean manner.

Actually, I totally agree with you. It's just that the ASF security team keeps forwarding CVE reports (likely generated by AI), and I was annoyed to have to make changes. 😂

[klesh]

Could you fix the linting, I will then merge the PR.