[Feature] Support an API-only backend and independently hosted frontend with an explicit compatibility contract

[nostalume]

Please confirm the following

• I have read and agree to AGPL-3.0 Section 15. The program is provided "as is" without any warranties; you bear all risks of using it.
• I have read and agree to AGPL-3.0 Section 16. The copyright holders and distributors are not liable for any damages resulting from the use or inability to use the program.
• I confirm my description is clear, polite, helps developers quickly locate the issue, and complies with community rules.
• I have read the OpenList documentation.
• I confirm there are no duplicate issues or discussions.
• I believe this issue must be handled by OpenList and not by a third party.
• I confirm this feature has not been implemented yet.
• I confirm this feature is reasonable and has general demand, not just my personal need.
• I have not read these checkboxes and therefore I just ticked them all, Please close this issue.

Feature Description

OpenList already keeps frontend source in a separate repository, but building
and serving the UI remain coupled to the Go process. build.sh obtains frontend
assets; public/public.go embeds a distribution; server/static/static.go
handles embedded, dist_dir and CDN modes while still initializing an HTML
entry point. The frontend accepts window.OPENLIST_CONFIG.api in
src/utils/config.ts but otherwise assumes the page origin/base path. This
request is for a supported runtime boundary, not a second frontend source
tree or a mandatory microservice deployment.

Please specify and support two modes: today's bundled UI and an API-only OpenList
backend paired with an independently hosted official frontend. A backend with
no UI distribution should start and serve its API and enabled protocols without
fetching or reading index.html. A separately hosted frontend should fail
clearly, rather than silently misbehave, when its API contract is incompatible.

Suggested Solution

1. Inventory the paired frontend/backend contract: API version and feature
   discovery; public settings/init; login/token/cookie/CORS/CSRF policy; path
   and download/signed-URL base; redirects; upload methods; task/event channels;
   error shapes; backend-kind-specific screens.
2. Make static-UI hosting an optional composition path, not a startup
   precondition of API routes. Keep bundled mode as the compatibility default.
3. Add an explicit deployment/configuration contract for API base and
   capability/version negotiation; protect secret-bearing admin routes as today.
4. Test both packaged modes with list, login, download/Range, upload and admin
   storage/settings smoke flows, including non-root base paths and mismatched
   frontend/backend versions. Document supported version combinations.

Additional Information

Relevant source: server/static/static.go, server/router.go, build.sh;
frontend src/utils/config.ts, src/app/App.tsx, src/utils/backend.ts,
src/pages/manage/routes.tsx. The frontend currently gates some admin pages by
backend kind and uses initialization-specific probing; those are cross-boundary
behavior, not evidence that every screen can be made independent. This request
should coordinate with any existing architecture refactor PRs, not supersede
them without review. #550 asks for a lite frontend build; it does not establish
an API-only backend contract.

AI Generated Content

• I used AI tools to generate this content
• I did not use AI tools to generate this content

AI model used

OpenAI Codex (exact model identifier not exposed to the agent)

[ILoveScratch2]

The API backend is clearly identical to the current deployment method.

Currently, the front-end and back-end are strongly interdependent, so there is no "API mismatch". Forcing an API integration would create a lot of unnecessary compatibility code.

Furthermore, an explanation of the necessity of the change must be provided; niche needs will not be proactively supported.

[nostalume]

I will refer your suggestion, currently I'm still investigating current architecture. If there's necessity or unnecessity, I will report immediately!