Axiopera: baixar versões antigas

Added
- A global --caller <agent>:<session ID> names the calling session where the host's session variable does not reach axiopera, such as over ssh, docker exec or WSL. Without it such an agent was taken for user and shared the terminal's inbox. axiopera guide tells an agent taken for user to add the option. See "指定调用方" in docs/usage.md.
- Each task records the model and effort it actually runs on, also when spawned without --model. status, the result line of each turn, the turn lines of log and the task title in top show them.
- axiopera models <agent> names in its first line what a spawn without --model runs on: the model from Axiopera's configuration, or else the one the agent's CLI picks from your own settings.
- Each task's events.jsonl gets a delivered event when inbox, result or a push hands something to a caller: who received it, how, and which events and results went along. Tools that read the data directory can tell from it what a command or a pushed message gave the agent. Pushes and reminders sent into Codex sessions carry a client message ID starting with axiopera:, which tells them from what the user typed.
Fixed
- Grok: --model and --effort were ignored and the task ran on Grok's default model and effort. They now apply, and an invalid value is reported with the model list.
- Codex: an approval request that Codex withdraws before anyone decides (network approvals, from Codex 0.167) no longer stays waiting for you, and no stale refusal reason is sent into the turn afterwards.
- Codex: messages pushed into a host session no longer begin with an [axiopera:<id>] mark.
Other notes
- Grok's read tier refuses models that run on another harness, such as codex: switching to one drops the read tier's tool limits. Use the work or full tier for those models.
- models --json: Grok's current_model is replaced by native_model and native_effort, which all three agents now report.
- A push that an earlier version left unconfirmed may be sent once more after the upgrade.
- Stop the daemon with axiopera daemon stop before replacing the executable.
- Updating the Codex plugin may require trusting it again.

Fixed
- macOS: inside an agent's sandbox, such as Claude Code's command sandbox, axiopera no longer starts the daemon and asks you to re-run the command outside the sandbox. A daemon started there stayed in the sandbox, passed it on to every sub-agent, and gave them the sandbox's network proxy settings.
- Windows: a process in the Codex sandbox can no longer add an instance of the daemon's named pipe and receive other clients' requests, including the environment that spawn sends. Clients also refuse a pipe served by a sandboxed process.
- If the data directory is read-only or not writable, axiopera asks you to re-run the command outside the agent sandbox instead of reporting only the system error.
- Linux: axiopera top no longer misses a task update that the daemon saves within a few milliseconds of the previous one.
Other notes
- Sub-agents can no longer run axiopera daemon stop, skill install or plugin cleanup; run them from the main session or a terminal. Version-mismatch errors shown to sub-agents no longer suggest daemon stop --force.
- On Linux the client does not check whether it runs in a sandbox. With Grok's --sandbox workspace and a data directory the sandbox can write, it can still start the daemon inside the sandbox.
- Stop the daemon with axiopera daemon stop before replacing the executable.
- Updating the Codex plugin may require trusting it again.