Four replication config knobs are silently inert: env.get resolves only names registered in CONFIG_PARAMS

`env.get(name)` → `configUtils.getConfigValue(name)` returns `undefined` for any name absent from
`CONFIG_PARAM_MAP` (built from `CONFIG_PARAMS` in core `utility/hdbTerms.ts`). These four are read in
`replication/replicationConnection.ts` but are not registered, so a value set in
`harperdb-config.yaml` is silently ignored and the compiled-in default always applies:

| read as | default that always wins |
|---|---|
| `replication_receiveEventHighWaterMark` | 100 |
| `replication_receiveYieldInterval` | 100 |
| `replication_copyCheckpointRecords` | 1000 |
| `replication_copyCheckpointMaxIntervalMs` | 5000 |

Confirmed empirically: a newly added param behaved exactly this way (config value ignored, default
applied) until registered in `CONFIG_PARAMS` — see harper-pro#733 and its companion core commit.

This matters beyond tidiness: incident reports have described tuning attempts on
`receiveEventHighWaterMark` and reasoned about it as an operator lever, when it cannot be changed at
all. Registering them makes the config do what the code already implies, but it does mean a
previously-ignored value in someone's config file would start taking effect — so it deserves its own
review rather than riding along with a fix.

Also worth an audit pass: any other `env.get('...')` call in harper-pro or core reading a name that
is not in `CONFIG_PARAMS`.

Start with core utility/hdbTerms.ts, where CONFIG_PARAMS and CONFIG_PARAM_MAP are defined, then inspect replication/replicationConnection.ts and its env.get calls. Audit the named configuration reads against the registered parameters and verify that configured values override the documented defaults. Done means the four parameters resolve correctly and the audit identifies no other unregistered names.

Written by the indexing model from the issue text.