fix(core): serve HTTP-01 ACME challenges via webroot provider

[Splicho]

Problem

The panel's Apply Free Cert UI fails with Invalid response from http://<host>/.well-known/acme-challenge/<token>: 404 on every domain. This is reproducible on a clean install of billionmail/core:4.9.3 with port 80 reachable and DNS pointed at the host:

Failed to apply for SSL certificate: error: one or more domains had a problem:
[mail.example.com] invalid authorization: acme: error: 403 ::
urn:ietf:params:acme:error:unauthorized :: <ip>:
Invalid response from http://mail.example.com/.well-known/acme-challenge/<token>: 404

Root cause

Two issues compound:

1. SafePath middleware blocks unauthenticated ACME requests. The hook at cmd.go returns 404 for any non-/api/ request without a session cookie. Let's Encrypt validation servers have no session, so they never reach the ACME handler.

2. The static file handler shadows the ACME proxy. manifest/config/config.yaml sets fileServerEnabled: true, which makes GoFrame's static file handler run ahead of bound handlers. Even with the SafePath gate bypassed, requests for /.well-known/acme-challenge/<token> are intercepted by the static handler and 404 because the file doesn't exist on disk. The bound proxy at s.BindHandler(\"/.well-known/acme-challenge/*any\", …) and the lego internal server at 127.0.0.1:60880 are never reached.

I confirmed (1) by adding a SafePath bypass and observing requests reach the bound handler. I confirmed (2) by adding a unique response body to the bound handler and seeing the static handler's stock Not Found returned instead.

Fix

• Switch the HTTP-01 provider from http01.NewProviderServer(\"127.0.0.1\", \"60880\") to lego's webroot provider, pointing at server.serverRoot. lego writes the challenge token to <serverRoot>/.well-known/acme-challenge/<token> directly. The existing static handler serves it. lego removes the file after validation completes.
• Remove the now-dead 60880 reverse proxy in cmd.go.
• Add a /.well-known/acme-challenge/ bypass to the SafePath middleware so LE can reach the webroot path.

The webroot path is read from config (server.serverRoot, defaulting to public/dist) instead of being hardcoded.

Diff stats

core/internal/cmd/cmd.go           | 23 +++++++++--------------
core/internal/service/acme/acme.go | 17 +++++++++++++----
2 files changed, 22 insertions(+), 18 deletions(-)

Verification

End-to-end test against billionmail/core:4.9.3 with the patched binary deployed:

Check	Result
POST /api/ssl/apply_cert	{\"success\":true,\"msg\":\"Certificate applied successfully\"}
letsencrypts row created	status=1, correct not_after, valid subject
TLS on :443 / :993 / :587	Issuer Let's Encrypt R12, CN matches host
Cleanup	<serverRoot>/.well-known/acme-challenge/ empty after issuance

Tested with two domains (mail.emudevs.gg, mail.synapse-themes.cc); both issued cleanly through the panel UI.

Notes

• No new dependency: github.com/go-acme/lego/v4/providers/http/webroot is part of the lego module already in go.mod.
• g.Cfg().MustGet(ctx, \"server.serverRoot\", \"public/dist\") is used so admins who customize serverRoot aren't broken.
• The DNS-01 paths (Cloudflare, Aliyun, Tencent, etc.) are unchanged.