[Feature]: `aioncore session create` and `session clear` — the agent-facing CLI can talk to conversations but cannot open or reset one

### Use case

One conversation acts as an orchestrator. It dispatches work to other conversations with `aioncore session send-message`, and that part works well today.

What it cannot do:

- Open a fresh conversation for unrelated work.
- Reset a conversation whose context has gone stale.

Both require a human to switch to the desktop app and click. That breaks unattended automation at exactly the point where the agent is otherwise self-sufficient: it can delegate, but it cannot manage the lifecycle of what it delegates to.

### What the CLI exposes today

`agent-facing-session-cli`:

- `session capabilities`
- `session list`
- `session send-message`

`agent-facing-config-cli`, conversation-adjacent:

- `config conversation rename`
- `config cron jobs …` and `config cron current …` — schedule a message into an **existing** conversation

The three-command session contract is hardcoded in
[`crates/aionui-app/src/commands/session_capabilities.rs`](https://github.com/iOfficeAI/AionCore/blob/main/crates/aionui-app/src/commands/session_capabilities.rs) —
`commands` lists exactly `capabilities`, `list`, `send-message`. There is no create, clear, delete, or compact anywhere in the agent-facing surface.

### The backend can already do this

[#772](https://github.com/iOfficeAI/AionCore/pull/772) (merged, from [#770](https://github.com/iOfficeAI/AionCore/issues/770)) added `POST /api/conversations/{id}/fork`, which creates a new conversation with a workspace, an agent binding, and lazy backend-session materialization.

So conversation creation already exists server-side, with the hard parts solved. What is missing is the CLI surface over it.

### Proposed shape (minimal)

```
session create # stdin: { workspace, agent (or assistant_id), name? } -> { conversation_id }
session clear # stdin: { conversation_id }
```

- `create` returns the new conversation id so the orchestrator can immediately `send-message` to it.
- `clear` resets an existing conversation's context in place, keeping its id — so scheduled cron jobs and any stored id stay valid.

`clear` discards conversation state and cannot be undone. It should be marked accordingly in the capability contract. The config CLI already has this concept: `CommandDescriptor` carries a `destructive` flag, and `config cron jobs delete` sets it (`config_capabilities.rs:138`). The session contract currently has no equivalent field, so one would need adding there.

Naming and exact input fields are open — the request is the capability, not the spelling.

### Prior art check

I searched issues and pull requests, open and closed, in both `iOfficeAI/AionCore` and `iOfficeAI/AionUi`, for conversation create / clear / reset / delete / compact and for agent-facing CLI framings. I found no existing issue or PR asking for this. The closest items are not the same request:

- [#772](https://github.com/iOfficeAI/AionCore/pull/772) / [#770](https://github.com/iOfficeAI/AionCore/issues/770) — fork, HTTP only, forks from a chosen message rather than opening a fresh conversation.
- [#795](https://github.com/iOfficeAI/AionCore/issues/795) / [#798](https://github.com/iOfficeAI/AionCore/issues/798) — trusted provisioning protocols, explicitly conversation-independent.

If I missed an existing issue, happy to close this as a duplicate.

Start with crates/aionui-app/src/commands/session_capabilities.rs, where the current session command contract is listed, then inspect the conversation fork endpoint added in PR #772. Compare the destructive flag handling in config_capabilities.rs:138. Done means the CLI exposes create and clear, returns a new conversation ID, preserves an existing ID on clear, and marks clear as destructive.

Written by the indexing model from the issue text.