mark Feature::RemoteControl as removed (#22386)

## Why

`remote_control` can appear in `config.toml`, CLI feature overrides, and
the app-server config APIs. Before this PR, app-server startup treated
`config.features.enabled(Feature::RemoteControl)` as the signal to start
remote control ([base
code](https://github.com/openai/codex/blob/5e3ee5eddfa5333f2e0b011880abf0cbf92bd295/codex-rs/app-server/src/lib.rs#L678-L680)).
That meant a user with:

```toml
[features]
remote_control = true
```

would accidentally opt every app-server process into remote control.
Remote-control startup should instead be a per-process launch decision
made by CLI flags.

## What Changed

- Marks `Feature::RemoteControl` as `Stage::Removed`, keeping
`remote_control` as a known compatibility key while making it
config-inert.
- Adds a hidden `--remote-control` process flag to `codex app-server`
and standalone `codex-app-server`.
- Plumbs that flag through
`AppServerRuntimeOptions.remote_control_enabled` and makes app-server
startup use only that runtime option to decide whether to start remote
control.
- Removes the app-server config mutation hook that reloaded config and
toggled remote control at runtime.
- Updates managed daemon spawning to use `codex app-server
--remote-control --listen unix://` instead of `--enable remote_control`.

Config APIs can still list, read, write, and set `remote_control`; those
operations just no longer affect remote-control process enrollment.

codex-rs/features/src/tests.rs

@@ -287,8 +287,8 @@ fn auth_elicitation_is_under_development() {
 }
 
 #[test]
-fn remote_control_is_under_development() {
-    assert_eq!(Feature::RemoteControl.stage(), Stage::UnderDevelopment);
+fn remote_control_is_removed_and_disabled_by_default() {
+    assert_eq!(Feature::RemoteControl.stage(), Stage::Removed);
     assert_eq!(Feature::RemoteControl.default_enabled(), false);
 }