Allow Hermes agents to use self-hosted Firecrawl service

### Problem Statement

I see the `nemohermes sandbox config set --key --value ` that should be used to update the agent's `/sandbox/.hermes/config.yaml`

but there seems to be no equivalent for updating `/sandbox/.hermes/.env` with nemohermes?

for example, I would like to add something like this line to my `/sandbox/.hermes/.env` to enable Firecrawl web search and scrape through a self-hosted firecrawl instance:

```
API_SERVER_PORT=18642
API_SERVER_HOST=127.0.0.1
API_SERVER_KEY=b538b9ddcf38aa0c7

# self-hosted Firecrawl host
FIRECRAWL_API_URL=http://firecrawl-service.local
```

but after making direct modifications to `/sandbox/.hermes/.env` I am no longer able to restart the hermes gateway with `nemohermes hm-4 gateway restart`:

```
Restarting Hermes Agent gateway in 'hm-4'...
Failure layer: relaunch quarantined - gateway restart failed for 'hm-4'.
GATEWAY_HEALTH_TIMEOUT
NEMOCLAW_CONTROL_STAGE=await-replacement
NEMOCLAW_SUPERVISOR_PID=36
NEMOCLAW_GATEWAY_PID=0
NEMOCLAW_START_LOG=[gateway] Hermes gateway respawned (pid 158051)
NEMOCLAW_START_LOG=[gateway] Hermes auxiliary repair failed; retrying while the exact gateway remains supervised
NEMOCLAW_START_LOG=[SECURITY] Hermes automatic respawn is quarantined until MCP integrity is restored by rebuilding the sandbox
Hermes gateway log tail (sanitized):
│ Press Ctrl+C to stop │
└─────────────────────────────────────────────────────────┘
WARNING gateway.run: No env user allowlists configured. Messaging platforms default to pairing/allowlist policies and will deny unknown senders unless you configure platform allowlists (e.g., TELEGRAM_ALLOWED_USERS=your_id) or explicitly opt in with GATEWAY_ALLOW_ALL_USERS=true plus dm_policy/group_policy: open on the platform.
WARNING gateway.run: Shutdown context: signal=SIGTERM under_systemd=no parent_pid=36 parent_name=bash loadavg_1m=0.65 parent_cmdline='bash /usr/local/bin/nemoclaw-start'
┌─────────────────────────────────────────────────────────┐
│ ⚕ Hermes Gateway Starting... │
├─────────────────────────────────────────────────────────┤
│ Messaging platforms + cron scheduler │
│ Press Ctrl+C to stop │
└─────────────────────────────────────────────────────────┘
The in-sandbox supervisor quarantined gateway relaunch after a startup refusal. Retrying the restart cannot clear it.
Restore the registered configuration and refresh its integrity metadata with `nemoclaw hm-4 rebuild --yes`.
Then make intended changes through supported commands such as `nemoclaw hm-4 config set` or `nemoclaw inference set --sandbox hm-4`, which update the configuration and its hashes together.
```

my apologies if this feature already exists, I could not find anything in the documentation and a consultation with claude mmade it seem like this capability does not yet exist

### Desired Behavior

have some documented mechanism to connect hermes to a self-hosted firecrawl instance. or be able to provide other `/sandbox/.hermes/.env` customizations without causing issues

### Scope and Exclusions

i dont know.

### Ongoing Ownership

i dont know.

### Placement and Support Expectations

i dont know.

### Validation Plan

i dont know.

### Compatibility Requirements

all

### Security or Privacy Impact

i dont know.

### Implementation Idea

_No response_

### Category

Platform

### Checklist

- [x] I searched existing issues and this is not a duplicate
- [x] I described the problem and desired behavior

Start by tracing `nemohermes sandbox config set`, `nemoclaw hm-4 config set`, and `nemoclaw hm-4 gateway restart`, then inspect how `/sandbox/.hermes/config.yaml` and `/sandbox/.hermes/.env` are registered and integrity-checked. Done means the supported mechanism for configuring `FIRECRAWL_API_URL` or other environment values is documented or implemented, and gateway restart no longer fails for those intended changes.

Written by the indexing model from the issue text.