[Plugin system]: support secure per-connection fields and customizable base fields

[debba]

Context

While implementing the external BigQuery driver, I used the connection-modal.extra_fields slot and the per-connection ConnectionParams.extra map. The new slot is useful for non-secret values such as authentication method, location, query timeout and maximum bytes billed.

BigQuery also needs per-connection credentials. Depending on the authentication mode, that can be a service account JSON document, an authorized user refresh token document, or an access token.

Current limitation

The slot context currently exposes:

{ driver, extra, setExtraField }

Values written through setExtraField are persisted verbatim in the connection object. There is no secret writer backed by the OS keychain, and no way for a plugin field to receive the same placeholder and dirty-state behavior as the built-in Password field.

For a normal external driver, the connection modal also always renders Host, Port, Username and Password. connection-modal.connection_content is only used for no_connection_required drivers and does not expose the complete connection form setters.

Impact on the BigQuery plugin

The driver can remain secure only by overloading the built-in fields:

• Database is the GCP Project ID
• Password is the service account JSON/path, authorized user JSON/path, or access token
• Host, Port and Username are ignored

This works, but produces a confusing form and prevents the plugin from presenting a properly named credential field. Putting the credential in extra would improve the label but would persist a private key or refresh token in plaintext.

The same limitation affects API and cloud drivers that need multiple per-connection secrets or do not use the traditional host/user/password model.

Suggested direction

One possible contract would add both of these capabilities:

1. Secure plugin-owned connection fields, stored per connection in the OS keychain and forwarded to the plugin only at runtime.
2. A way to hide, relabel or replace the common Host, Port, Username, Password and Database fields for a specific external driver.

This could be declarative manifest metadata such as connection_fields, or an expanded slot context with form and secret setters. The exact API is less important than keeping persistence and keychain behavior owned by the host.

Acceptance criteria

• Two saved connections for the same plugin can use different secret values.
• Secret values are never written to connections.json or config.json.
• Editing a connection can show a stored-secret placeholder without revealing the value.
• Test Connection and Save receive the resolved secret values.
• A plugin can hide or relabel common connection fields it does not use.
• Existing plugins and current UI slots remain backward compatible.

Current workaround

The BigQuery plugin keeps non-secret options in extra and uses the existing Password field for all credential material so that users can enable keychain storage.