Salesforce Kamelets only support username/password authentication (no JWT/keystore)

## Summary

Every Salesforce Kamelet in the catalog authenticates with username and password only. `camel-salesforce` supports four authentication types; the Kamelets expose one.

Raised originally as a secondary question in #1546 ("does the kamelet salesforce connector support keystores for authentication? I didn't see the parameters"). That issue is really about Pub/Sub support, which #3012 addresses, so this splits the authentication half out before it is lost.

## Current state

All five Kamelets build their component bean the same way:

```yaml
- name: local-salesforce
type: "#class:org.apache.camel.component.salesforce.SalesforceComponent"
properties:
clientId: "{{clientId}}"
clientSecret: "{{clientSecret}}"
userName: "{{userName}}"
password: "{{password}}"
loginUrl: "{{loginUrl}}"
```

| Kamelet | auth properties exposed |
|---|---|
| `salesforce-source` | clientId, clientSecret, userName, password |
| `salesforce-create-sink` | clientId, clientSecret, userName, password |
| `salesforce-update-sink` | clientId, clientSecret, userName, password |
| `salesforce-delete-sink` | clientId, clientSecret, userName, password |
| `salesforce-composite-upsert-sink` | clientId, clientSecret, userName, password |

(`salesforce-pubsub-source`, added in #3012, follows the same pattern for consistency — it would be included in whatever is decided here.)

The component offers considerably more:

```
authenticationType: enum ['USERNAME_PASSWORD', 'REFRESH_TOKEN', 'CLIENT_CREDENTIALS', 'JWT']
jwtAudience: String
keystore: org.apache.camel.support.jsse.KeyStoreParameters
instanceUrl: String
```

So JWT bearer flow — the flow Salesforce recommends for server-to-server integrations, and the one that avoids storing a user password — is unreachable from the catalog.

## Why it is not a trivial addition

`authenticationType`, `jwtAudience` and `instanceUrl` are plain scalars and would drop straight in. `keystore` is the problem: it is typed `KeyStoreParameters`, an object, so there is no scalar to bind a Kamelet property to.

That leaves the same fork already faced for the OpenSearch Kamelets in #3000:

1. **Build the `KeyStoreParameters` bean inside each template** from scalar properties (path, password, type). Matches the catalog's usual idiom — `aws-redshift-sink` builds its `BasicDataSource` this way. But Kamelet beans are created unconditionally, so a username/password user would still get a keystore bean constructed, and it needs checking whether an empty one is harmless here.
2. **Accept a bean reference** — one optional property taking `#bean:myKeystore`. This is what #3000 does for `sslContextParameters`. Minimal and safe, but pushes bean registration onto the operator.

Whichever is chosen should be applied consistently across all six Salesforce Kamelets rather than one at a time, since the auth block is currently identical in each.

## Suggested scope

- add `authenticationType`, `jwtAudience` and `instanceUrl` as scalar properties
- decide between (1) and (2) above for `keystore`
- apply uniformly to all six Kamelets
- keep `USERNAME_PASSWORD` as the default so existing bindings are unaffected

Happy to implement once the `keystore` approach is chosen — that decision is the only part that is not mechanical.

---
_Claude Code on behalf of Andrea Cosentino_

Inspect the six Salesforce Kamelet templates and compare the bean-reference approach in #3000 with the scalar bean construction used by aws-redshift-sink. Decide how to expose keystore authentication, then apply the chosen authentication properties consistently while retaining USERNAME_PASSWORD as the default.

Written by the indexing model from the issue text.