fix(config): stop a partial POST /api/config from clearing omitted sections

[Davixk]

What breaks: a POST /api/config body that omits a top-level section deletes that section from disk. Posting only {"log_level":"debug"} wipes debrids — configured providers and their api keys included — along with every other key the caller didn't mention.

Why: handleUpdateConfig in pkg/server/api.go decodes the body into a zero config.Config, so any absent top-level key ends up as its zero value, and the subsequent newConfig.Save() writes that zero value out.

The fix: merge on missing. Config.PreserveMissingSections copies every top-level section whose JSON key is absent from the posted body out of the live config before validation and save. Presence still wins wholesale, so an explicitly posted empty value ("debrids": []) clears exactly as before, and full-config POSTs (the web UI path) decode identically with and without the merge — there's a test asserting that.

Evidence: running in production on a ~47,000-entry library. Tests cover partial / explicit-empty / full POSTs at both the merge layer and the HTTP handler (asserting on-disk state); the partial-POST tests fail on beta without the change.

Split out of a second config-API fix (explicit download_uncached: false not persisting) so each is reviewable on its own; the two are independent.

[Davixk]

Marking this draft — the fix is right but the verb is wrong, and I'd rather correct that than have you review it as-is.

Making POST merge is really just PATCH semantics under the wrong verb. I'm reworking this to expose PATCH (partial merge) and PUT (full replace) with honest contracts, keeping POST as a deprecated alias so existing clients don't break. Will un-draft once that's in.