Webui dynamic config

[ServeurpersoCom]

Implemented dynamic config loading and reset behavior:
    - On startup, the app checks if localStorage.config exists and is non-empty. If not, it fetches defaults from the server.
    - The "Reset to default" button now properly:
        - fetches fresh config from the server,
        - updates localStorage,
        - calls saveConfig() to refresh the app state instantly.
    - Removed reliance on hardcoded CONFIG_DEFAULT. The server is now the single source of truth.

[TeeAaTeeUu]

For me the main problem with the WebUI defaults is that those are always being sent. This seems to be trying to sync WebUI with the llama-server values, but still sending the params even if they would be matching the backend. Specifically these two parts:

https://github.com/ggml-org/llama.cpp/blob/8c83449cb780c201839653812681c3a4cf17feed/tools/server/webui/src/utils/app.context.tsx#L208-L233

https://github.com/ggml-org/llama.cpp/blob/9a390c4829cd3058d26a2e2c09d16e3fd12bf1b1/tools/server/server.cpp#L250-L274

I think it makes sense sync frontend and backend, but because it's not always possible to keep them in sync, allow NOT sending the defaults, to fully rely on the backend values. This would also better align with https://github.com/ggml-org/llama.cpp/issues/13367 and similar, where WebUI might be sending requests to different models with different settings, and keeping multiple defaults in WebUI might become hard to maintain.

[ServeurpersoCom]

You're absolutely right — this is the core issue I ran into as well. The current behavior of always sending the full WebUI config overrides any server-side defaults, even when values haven’t been changed by the user. This breaks the ability to tune the server per model, which is especially important when exposing a shared WebUI for others to use.

Ideally, the WebUI should only send parameters that have been explicitly changed by the user. That way:

If a value matches the server default, it’s omitted from the request.

If a value differs (i.e. manually changed in the UI), it’s included as an override.

And there’s a Reset to server defaults button to wipe all local changes and fully re-sync with the backend.

To keep the frontend simple, when resetting a field, we could just clear it or show something like "default from server", allowing the backend to handle the fallback logic. That way, the WebUI doesn’t have to duplicate config logic — it only overrides selectively, when explicitly told to.

For example, if I deploy a well-tuned MoE model on the server, I want a friend using the WebUI to benefit from the correct sampling settings and get optimal performance out-of-the-box — not be stuck with unrelated or legacy settings hardcoded from the webui.

This would make the UI much easier to maintain, while preserving clean server-driven behavior.