[Bug] copaw worker: active_skills/ updates from apply --zip don't propagate to workspaces/default/skills/, breaking skill hot-reload

## Summary

`hiclaw apply worker --zip` against an **existing** copaw worker
updates the package in MinIO and the worker's `active_skills/`
directory, but **does not** sync those changes into
`workspaces/default/skills//`. The LLM's `execute_shell_command`
tool invocations resolve to the workspace path, so user code / config
changes pushed via apply --zip are **invisible to the running agent**.

This is equivalent to "copaw workers cannot hot-reload skill code or
config after their first deploy" — a hard blocker for any skill that
needs to ship updates without recreating the worker.

## Environment

- HiClaw v1.1.0 GA, embedded mode, macOS Docker Desktop
- Worker: copaw runtime
- Skill: a custom skill (streetlight) with `scripts/_client.py` plus
a non-secret `service.json` config file under `skills//`

## Reproduction

1. Create a copaw worker with package A (skill v1 in `skills//scripts/`)
2. `hiclaw apply worker --zip .zip --name `; verify it works
3. Edit the skill code or add a new file (e.g. `service.json`)
4. `hiclaw apply worker --zip .zip --name ` (same worker name)
5. Inspect the container:

```
docker exec hiclaw-worker- ls /root/.hiclaw-worker//.copaw/active_skills//
docker exec hiclaw-worker- ls /root/.hiclaw-worker//.copaw/workspaces/default/skills//
```

`active_skills/` reflects pkg B; `workspaces/default/skills/` is
still pkg A.
6. Send a Matrix message that triggers the skill. **Observed in the
agent's session JSON / tool trace** (not inferred): the agent calls
`execute_shell_command` with a path under
`workspaces/default/skills//scripts/`, runs the **old** code,
returns old output.

## Diagnostic evidence

The agent's session JSON (under
`/.copaw/workspaces/default/sessions/.json`) shows the
resolved tool-call path:

```
"name": "execute_shell_command",
"input": {"command":
"python3 /root/.hiclaw-worker//.copaw/workspaces/default/skills//scripts/.py"}
```

— always the workspace path, never the active_skills path.

`md5sum` confirms the two paths drift after any post-create apply --zip:

```
active_skills//scripts/_client.py
workspaces/default/skills//scripts/_client.py
```

## Workaround

```bash
docker exec sh -c \
'cp -av /root/.hiclaw-worker//.copaw/active_skills//. \
/root/.hiclaw-worker//.copaw/workspaces/default/skills//'
```

Effective immediately; agent picks up new code on next tool call. But
it's manual + per-container + needs to be re-run on every package
update.

## Suggested directions

- (a) On reconcile completion (post-merge), copaw should resync
`workspaces/default/skills//` from `active_skills//`
(or a single shared source). Most surgical.
- (b) Eliminate the duplicate copy entirely; `workspaces/default/skills/`
could be a symlink / overlayfs view of `active_skills/`. Cleanest, but
riskier if there are workspace-specific edits expected.
- (c) Add an explicit "skill resync" lifecycle hook the agent can call,
documented in the skill update workflow.

(a) keeps the existing two-tier model but closes the sync gap.

## Severity

**High** for any production deployment with custom skills:

- skill bug fixes never reach the agent — operators must manually copy
files inside the container or delete/recreate the worker, risking
room/reconcile state and operational drift
- skill config files (`service.json`, `*.example`) added in updates
are silently absent at runtime
- error reporting reflects the OLD code's error messages, masking
whether a "service unavailable" reply is genuine or a stale-skill
artifact

## Related

- HiClaw #711: AGENTS.md merge race during apply --zip update — same
update path, separate issue