deploy_component peer replication ignores client rejectUnauthorized setting

## Problem

`deploy_component` with `replicated: true` propagates the deployment to peer nodes via an internal replication mechanism. However, this peer-to-peer step uses the node's default TLS settings — it does **not** respect the `rejectUnauthorized: false` (or equivalent) flag that the requesting client may have passed on the `add_node` call.

In environments using self-signed TLS certificates (integration tests, on-prem clusters without a trusted CA), the peer replication step fails with:

```
self-signed certificate in certificate chain
```

Before core PR #1334, these failures were silent — the `deploy_component` still returned 200 and the deployment was simply not replicated to the failing peer. After #1334, the operation correctly returns non-2xx, surfacing the failure — but this exposed how many callers were silently relying on the previous behavior.

The immediate workaround (`ignore_replication_errors: true`) suppresses the error response, but it doesn't fix the underlying problem: deployments don't replicate to peers when self-signed certs are in use.

## Expected behavior

Either:
1. `deploy_component` peer replication should inherit the cluster's configured `rejectUnauthorized` / TLS settings (the replication connection already negotiated these on `add_node` — peer deploy should reuse the same trust chain), or
2. A `replication.rejectUnauthorized: false` config option (already discussed for the WS replication path, see `partitionHealConvergence.test.mjs` header) should also apply to peer-deploy calls.

## Impact

- All integration/stress tests using self-signed certs must add `ignore_replication_errors: true` to avoid false failures (harper-pro #413).
- Real clusters behind a corporate CA that isn't in the Node trust store hit the same problem silently (pre-#1334) or loudly (post-#1334).

## Notes

The self-signed cert issue is distinct from the `rejectUnauthorized: false` flag on `add_node` operations — that flag gates the subscription-setup WS handshake, not subsequent peer-deploy calls. These two code paths apparently use different TLS contexts.

Start by tracing the TLS context used by deploy_component peer replication and compare it with the add_node subscription setup. Read the replication.rejectUnauthorized discussion in partitionHealConvergence.test.mjs and identify how peer-deploy calls obtain their settings. Done means self-signed TLS replication works with the documented configuration and existing replication behavior remains covered by tests.

Written by the indexing model from the issue text.