v0.43.0 - the rule create had and update did not

RayRAG 0.43.0

The create path refused a configuration the update path accepted

0.40.0 taught the create path to reject a configuration the connector cannot use — an s3 source with no
bucket, a feishu source with no token — because such a record is stored happily and only fails later, at sync
time. That rule was never applied to updates:

PATCH /api/v1/data_sources/{id}   {"target": ""}    -> 200, code 0, record now unusable

Clearing one field in the detail form produced exactly the record create exists to prevent. The same check now
runs on the record an update would store, naming the field and the kind:

400  target is required for s3

It only runs when the request touches a credential field, so renaming a record that predates the rule keeps
working.

That stricter rule immediately found a second bug: two-field credentials were never saved

It refused a patch that supplied WebDAV's credentials.username / credentials.password — correctly, and for a
reason worth knowing: the form collects two fields, the connector authenticates with one user:secret
string, and nothing joined them. The pair stayed in extra, token stayed empty, the save reported success, and
the source could never connect.

form fields	token	connector
credentials.username + credentials.password	user:secret	WebDAV
credentials.aws_access_key_id + aws_secret_access_key	key:secret	S3, GCS, Oracle, R2
credentials.confluence_username + confluence_access_token	email:api_token	Confluence
credentials.account_name + account_key	name:key	Azure Blob

Both halves must be present, so half a pair never becomes a fabricated user: — the single-key list is tried
instead.

Found while walking the form, not fixed here

The Token box always renders empty (the stored token is never sent to the browser) and the payload keeps it only
when non-empty:

var token = document.getElementById('dsDetailToken').value;
if (token) payload.token = token;

That default is right for an untouched box, but it leaves no way to remove a stored credential — the box can be
cleared, no token field is sent, and the server answers 200 with the old value. The capability exists in the API
({"token": ""}) and is now governed by the rule above. Fixing it needs an explicit control; always sending the
field would wipe every credential on every save, which is far worse. Left for the next round rather than rushed
into this build.

Verification

• 2270 tests passed, 0 failed, 27 ignored.
• Three behaviours pinned: clearing a required field is refused and leaves the stored record untouched, a
  rename of the same record still succeeds, and completing the configuration is accepted. Proven by removing the
  rule: the update returns code 0 and the test fails.
• All four credential pairs pinned, half a pair asserted to fall through to the single-key list.
• Live: PATCH {"token": ""} answers 400 token is required for webdav; a rename-only patch answers code 0.
• Layout suites: nine suites, 0 page errors.

Upgrading

Nothing to do — same Compose file, same rayrag service. PostgreSQL and zvec remain the defaults in both the
Docker and the plain-Linux deployment.