exec-sink: the documented args / ce-args header interface has no effect (camel-exec gates control headers behind allowControlHeaders)

`exec-sink` documents an `args` / `ce-args` input header, and its doc partial says:

> === Optional Headers
> The Kamelet supports the following optional headers:
> - `args` / `ce-args`: Command line arguments to pass to the executable

The template maps them onto the component header:

```yaml
- choice:
when:
- simple: "${header[args]}"
steps:
- setHeader:
name: CamelExecCommandArgs
simple: "${header[args]}"
- simple: "${header[ce-args]}"
steps:
- setHeader:
name: CamelExecCommandArgs
simple: "${header[ce-args]}"
- to:
uri: "exec:{{executable}}"
```

But `camel-exec` does not read that header. Tested on Camel 4.22.0 with an identical route shape as a control:

| how the argument is passed | stdout | header afterwards |
|---|---|---|
| `exec:echo?args=URIARGS-WORK` (URI parameter) | `URIARGS-WORK` | n/a |
| `CamelExecCommandArgs` header, `exec:echo` | *(empty)* | still present, unconsumed |

`camel-exec` reads its command headers with `getAndRemoveHeader`, so a header that survives the call was never looked at. The same is true of `CamelExecCommandExecutable`, tested both ways:

| endpoint | header | command that ran |
|---|---|---|
| `exec:hostname` | `whoami` | `hostname` |
| `exec:whoami` | `hostname` | `whoami` |

So `exec-sink` cannot pass arguments at all today — the documented interface is dead code, in the same way `mail-sink`'s `ce-*` mappings were in #2957.

Two things follow, and they are separable:

1. **Upstream.** The component catalog documents `CamelExecCommandArgs` as *"Command-line argument(s) to pass to the executed process ... Overrides any existing args in the URI"* and `CamelExecCommandExecutable` as *"Overrides executable in the URI"*. Neither happens. That is an `apache/camel` matter — either the behaviour or the documentation is wrong. Worth a Jira before anything is changed here, since the fix direction for this Kamelet depends on the answer.

2. **Here.** If upstream confirms the headers should work, this Kamelet is fine once the component is fixed and nothing needs doing. If upstream says URI-only is intended, `exec-sink` needs a different mechanism to accept arguments — most likely a declared property interpolated into the endpoint, or `toD` — and the doc partial needs correcting either way.

I have not proposed a fix here because the right one depends on (1).

Related: #2957 (the same defect class in `mail-sink` and `redis-sink`), #2973 (which strips the other `CamelExecCommand*` headers as insurance), #929.

_Claude Code on behalf of Andrea Cosentino_