`ironclaw skills list` cannot see skills that the runtime writes

Skills an agent installs are invisible to the CLI, and so are skills belonging to any user the CLI was not configured with. Someone debugging "why can't my agent see its skill" gets an empty list from the tool they would naturally reach for, which points them at the wrong problem.

Two separate gaps, same command:

1. It reads a different store than the runtime writes. Since #7168 the runtime's skill mounts are database-backed — db_backed_skill_management_mount_view, the same tree the reader and Settings use. ironclaw skills list still goes through build_existing_standalone_skill_management_port(owner_id, standalone_storage_root), a disk store. So a skill an agent installs through skill_install lands in the database and never shows up in the CLI.

2. It only ever looks at one owner. The owner comes from configuration, so a user created at runtime — by WebUI login, for example — has no way to be named. There is no --user, and the JSON output carries no owner fields, so a caller cannot tell whose skills they are looking at either.

There is also a third, smaller thing: the command rejects profile=production outright ("supports profile=local-dev, ... hosted-single-tenant; got profile=production"), so on a production-profile deployment it cannot run at all.

Reproduce

1. Have an agent call skill_install, or create a user through WebUI login and install a skill as them.
2. ironclaw skills list — the skill is absent, exit code 0, no diagnostic.
3. The same skill is present in the runtime: ask an agent in that user's scope to list its skills and it is there.

What a fix probably needs

• Read the store the runtime writes.
• Discover owners rather than assume one, with --tenant / --user to narrow.
• Add tenant and user to the JSON entries so output is attributable; the skills array shape can stay as it is.
• Decide what the command should do under profile=production.

Filing as an issue rather than a PR because the storage design is yours and the owner-discovery shape should be your call. Happy to implement whichever direction you prefer.

https://claude.ai/code/session_01MciaHokSWPNsR692c2cTw1