[Bug]:fix(aistio): agent_shares table is never created — Agent Share API fails with "relation agent_shares does not exist", and console Agent detail tabs are hidden because tierForCurrentUser is never returned

Describe the bug

In agentscope-service (the aistiod Go control plane), the Agent sharing feature reads and writes a table named agent_shares, but the startup schema migration (aistio/internal/product/migrate.go) never creates
that table — it only creates a legacy, unused resource_shares table. As a result, every Share operation fails with a Postgres error.

There is a closely related second defect: the console frontend (frontend/src/components/AgentLayout.tsx) gates every Agent detail tab (Workspace / Skills / Tools / Subagents / Channels / Settings, all
minTier: 'RUN') on a field called tierForCurrentUser, but the Go agent API never returns that field. With tierForCurrentUser absent, the tab strip is not rendered at all — even for the agent owner — so
Tools/Skills/Subagents/etc. are unreachable from the UI.

To Reproduce

1. You code / environment: check out main and bring up the AgentScope Service stack (the control plane is the Go aistiod binary; schema is created by aistio/internal/product/migrate.go on startup).
2. How to execute:
either via docker compose
docker compose -f agentscope-service/docker-compose.yml up --build -d
or via the local dev stack
cd agentscope-service && scripts/dev-down.sh && BUILDER_REBUILD=1 scripts/dev-up.sh
2. Then open the console at http://localhost:8080, log in (admin/admin), and create an Agent.
3. See error:
- (a) Open the Agent's detail page — the whole tab strip (Workspace / Skills / Tools / Subagents / Channels / Settings) is missing.
- (b) Click the ↗ Share button (or call GET /api/agents/{id}/shares / POST /api/agents/{id}/shares) — the request fails with a 500.

Expected behavior

- Opening an Agent's detail page should show all detail tabs for the owner (owner implicitly holds EDIT), and show read-only/clone-only views for users an agent was shared with.
- Listing/adding/revoking shares should succeed and persist grants, supporting both per-user grants (grantee_type=USER) and workspace-wide grants (grantee_type=WORKSPACE, grantee_id='*') with the
CLONE/RUN/EDIT tiers.

Error messages

GET /api/agents/{id}/shares → 500
{"error":"ERROR: relation \"agent_shares\" does not exist (SQLSTATE 42P01)"}
(The same SQLSTATE 42P01 is raised by POST .../shares, by the admin user-deletion cascade DELETE FROM agent_shares ..., and by any agent-list visibility query that joins agent_shares.)

For the hidden-tabs defect there is no server error; the frontend simply receives an agent object without tierForCurrentUser, so tierImplies(null, 'RUN') is false and no tab is rendered.

Environment (please complete the following information):

- AgentScope-Java Version: 2.0.3-SNAPSHOT — agentscope-service, aistiod control plane (Go module github.com/spring-ai-alibaba/aistio)
- Java Version: 17 (Temurin 17.0.19)
- OS: macOS (Darwin 25.6.0); also reproduced in the Linux docker-compose stack
- Database: PostgreSQL 17, schema cp

Additional context

Root cause:

- handlers_agent_extras.go (listShares/addShare/revokeShare) and handlers_admin.go (user-deletion cascade) all operate on agent_shares, but migrate.go has no CREATE TABLE IF NOT EXISTS agent_shares — only the
structurally different, unused resource_shares (which has grantee_user_id/permission and cannot represent grantee_type or the CLONE/RUN/EDIT tiers).
- handlers_agents.go never populates tierForCurrentUser in the agent JSON, while AgentLayout.tsx requires it to render tabs.

Suggested fix (already prepared on a branch based on main):

1. Add the agent_shares migration (columns owner_id, agent_id, grantee_type, grantee_id, tier, created_at, with a unique constraint on (owner_id, agent_id, grantee_type, grantee_id) matching the addShare ON
CONFLICT clause, plus lookup indexes). The migration is idempotent (CREATE TABLE IF NOT EXISTS), so existing deployments pick it up on aistiod restart — no data volume reset required.
2. Return tierForCurrentUser from the agent API: owners resolve to EDIT; other users get their highest CLONE/RUN/EDIT grant from agent_shares (a direct USER grant or a WORKSPACE '*' grant), and scope list/get
to agents the caller owns or has a share for.
3. Mark resource_shares as a legacy/unused table.

---