register --config silently drops append_mcp_path, and --overwrite can reset is_enabled on an enabled server

## Summary

Two related problems in `register --config`, both cases of the config file appearing to control state that it does not:

1. **`append_mcp_path` in a config file is silently ignored.** The register endpoint accepts it as a form field, but the CLI never sends it, so the value is dropped with no error.
2. **`register --overwrite` can silently disable an enabled server.** Re-registering flipped `is_enabled` from `true` to `false` for one server, while an identical operation on another preserved it. I could not isolate the trigger — details below.

Both surfaced while registering Salesforce Hosted MCP (Headless 360), where each broke the server in a way that was slow to attribute.

## 1. `append_mcp_path` is dropped by the CLI

`registry/api/server_routes.py:1358` declares it, and 1491-1492 persists it:

```python
append_mcp_path: Annotated[bool | None, Form()] = None,
...
if append_mcp_path is not None:
server_entry["append_mcp_path"] = append_mcp_path
```

But `grep append_mcp_path api/registry_client.py api/registry_management.py` returns **nothing** — the CLI never forwards it. So this in a config file has no effect:

```json
{ "path": "/salesforce-headless-360", "append_mcp_path": false }
```

The value only persists via `patch-server`:

```bash
patch-server --path /salesforce-headless-360 --patch '{"append_mcp_path": false}'
```

### Why it matters

Salesforce's hosted MCP endpoint takes JSON-RPC at its root and 404s on `/mcp`. Verified directly:

```
POST .../platform/headless-360 -> HTTP 200
POST .../platform/headless-360/mcp -> HTTP 404
```

With the flag silently dropped, the gateway appends `/mcp` and every call fails. The failure surfaces as an upstream 404/401 rather than anything pointing at the ignored setting.

Same shape as #1558 (`search endpoint_url ignores append_mcp_path`), but on the registration path rather than search.

### Suggested fix

Forward it from the config file, as the other fields are. Alternatively reject unknown/unsupported config keys with a 4xx so a dropped setting is loud rather than silent — that would have caught this immediately.

## 2. `register --overwrite` can reset `is_enabled`

Reproduced on the Salesforce entry:

```
BEFORE: is_enabled=true append_mcp_path=false
register --config --overwrite (exit 0)
AFTER: is_enabled=false append_mcp_path=false
```

Repeatable — it happened on every attempt with that config (5+ times during bisection).

### What I could NOT establish

The same operation on `/currenttime/` **preserves** `is_enabled=true`, twice confirmed. So this is not universal to `--overwrite`, and I could not find the trigger:

- Neither config contains `is_enabled`, so it is not an explicit false in the file.
- Removing each field the Salesforce config has and `currenttime.json` lacks — `append_mcp_path`, `visibility`, `status`, `tool_list`, `supported_transports` — still reset it every time. So no single one of those is responsible.
- Path shape differs (`/salesforce-headless-360` vs `/currenttime/` with a trailing slash) but I did not test that in isolation.

Possibly a field combination, the path form, or something about entries that carry `egress_auth_mode` (the Salesforce entry had egress configured; `currenttime` did not). I am filing with the reproduction rather than a root cause because I could not narrow it further, and would rather report it accurately than guess.

`registry/api/server_routes.py:552` indexes a new entry with `is_enabled=False`, and 1631 reads `is_service_enabled(path)` on the update path — so the two branches clearly differ in intent. That is where I would look.

### Why it matters

A disabled server gets no nginx route, so it returns 405 and disappears from the dashboard, while `list` still shows it (marked `✗ ⚫`). Re-registering to update metadata can therefore take a working server offline silently. Related to #1578 (registration not enabling) but distinct: this is *losing* an existing enabled state.

## Environment

Registry 1.28.0, docker-compose, MongoDB CE backend. Five registered servers; only the Salesforce entry exhibited (2).