mcp: config add/remove handlers bypass readonly guard

### Bug

The `deploy` and `delete` handlers check `s.readonly` and refuse to act when the server is in readonly mode:

```go
if s.readonly {
err = fmt.Errorf("the server is currently in readonly mode...")
return
}
```

However, the six config mutation handlers have no such guard:

- `configEnvsAddHandler`
- `configEnvsRemoveHandler`
- `configLabelsAddHandler`
- `configLabelsRemoveHandler`
- `configVolumesAddHandler`
- `configVolumesRemoveHandler`

These tools are annotated with `ReadOnlyHint: false` and some with `DestructiveHint: ptr(true)`, correctly declaring them as mutative, but the handlers execute unconditionally regardless of `s.readonly`.

### Impact

In readonly mode, an AI agent can freely modify `func.yaml` by adding or removing environment variables, labels, and volumes. This directly contradicts the purpose of readonly mode.

### Fix

Add the same `s.readonly` guard to all six config mutation handlers, consistent with the `deploy` and `delete` handlers.

Start at the six named config mutation handlers and compare their control flow with the existing deploy and delete handlers. Add consistent readonly behavior to each config add/remove entry point, then verify that all six refuse changes when s.readonly is enabled and continue to allow them otherwise.

Written by the indexing model from the issue text.