feat(agent-team): support spawning a team member from an existing agent (AgentCreate from_agent)

## Background / use case

We're building a multi-tenant agent platform on top of agentscope 2.0.2's `app` layer (`create_app`), reusing the full team runtime (message bus / wakeup / inbox / the four team tools / distributed lock / worker persistence).

A core use case we (and, we believe, many users) need:

> Users assemble a team out of **already-configured agents** (each with its own tools / skills / MCP / system prompt). At runtime the leader spins them up as members, and **each member should directly reuse that agent's existing capabilities**.

## Current obstacles

- **C1** — `AgentCreate` always **creates a brand-new** `source="team"` agent as the worker (a fresh uuid bound to the worker session), so there's no way to use an *existing* agent as a member. (`_agent_create.py:423-462`)
- **C2** — A worker's toolset is decided by the **agent-level** `AgentRecord.source` (`get_toolkit` reads `get_agent(session.agent_id).source`), so even if a `source="user"` agent were given a team session, it wouldn't receive the member toolset. (`_toolkit.py:150-168`)

Because of C1+C2, reusing an existing agent today requires a heavy host-side workaround (a shadow worker agent per reused agent + a worker→source mapping + redirecting capability resolution back to the source agent at runtime). It works, but it's complex and error-prone.

## Proposal

> We understand the current worker design (a one-shot, team-scoped standalone agent) has real merits — clean lifecycle (`TeamDelete` removes agent+session together), independently customizable name/prompt, config isolation. This is **not** a claim that the design is wrong; it's a request for an **optional** capability for the "reuse an existing agent" case.

Add an **optional** `from_agent=` parameter to `AgentCreate`: spawn a member **session** from an existing agent (**without creating a new agent**); the session's tools are cut to the member role and capabilities resolve from that agent's existing config. When `from_agent` is omitted, the current "create a new worker agent" behavior is unchanged.

**Possible internal adjustment (your call):** since the same agent can now run both standalone and as a member, the member role can no longer be decided solely by `AgentRecord.source`. A direction consistent with the existing model is to decide the role at the **session** level — team membership already lives there (`SessionRecord.team_id`).

**Candidate discovery — not agentscope's concern:** which agents a leader may use as members is supplied by the caller in the leader's context; `from_agent` just takes one agent id. Visibility / tenant isolation is naturally gated by the existing `get_agent(user_id, from_agent)` (not visible → not found → `AgentCreate` fails). No "available members" registry needed.

## Backward compatibility / impact on existing teams

- `from_agent` as an **optional new param** is backward compatible.
- If member-role detection is adjusted to support it, note that `TeamData.member_ids` currently stores **agent_id** (`_agent_create.py:482`); switching to a session identifier would touch existing data/semantics — a **breaking risk**. Suggested compatible route: **add a branch rather than replace** (keep the agent-level check, add a session-level one), so existing teams aren't broken.

## Why not just add a "source marker" field?

A field that lets a worker carry "which agent it came from" only patches the shadow-worker approach: the worker is still a newly-created standalone agent, the host still maintains a worker→source mapping and redirects capability resolution at runtime — treating the symptom, not the cause. What we want is for the member to **be** that existing agent.

## Relation to #1890

Orthogonal to the subagent-HITL-to-leader design (#1890), which we also rely on and support.