Add an admin-only SimpleChat Admin action that restricts any agent using it to admins

#1347 の capability audit から始め、次に application/single_app/functions_simplechat_operations.py、functions_authentication.py、functions_governance.py、route_backend_agents.py を読み、アクションの登録、認可、一覧表示を把握します。続いて、authoring feedback に関連する modal ファイルと plugin ファイルを追跡し、その後 functional_tests/route_tests/ と指定されたドキュメントページを更新します。完了条件は、admin アクションとその agents がフィルタリングされ、実行が独立して保護され、governance によって admin の下限が弱められず、admin UI のフィードバックが存在することです。

Summary

Add a second, separate action type — SimpleChat Admin — for SimpleChat operations that only an application admin should be able to perform. The action is invisible to non-admins, and any agent that references it becomes admin-only. That restriction is enforced in code as a floor, not left to governance policy.

User Value

Admin-capable operations are currently mixed into the general SimpleChat action. make_group_inactive is the clearest example: it already requires Control Center admin access, so a normal user can enable it on an action, attach it to an agent, and only discover the problem as a runtime permission failure. That is a late and confusing way to learn about a permission boundary.

A dedicated admin action makes the boundary explicit at design time, keeps privileged operations out of the capability list that ordinary authors browse, and gives admins one obvious place to look when auditing who can do what.

Proposed Behavior

Visibility

• Non-admin users never see the SimpleChat Admin action type in the action picker, the action type list, or any action listing API.
• Non-admin users never see an agent that references the admin action — in any agent list, catalog, picker, popular-agents surface, or template listing.
• If an admin attaches the action to an otherwise ordinary agent, that agent disappears for non-admins rather than failing later.

Enforcement

• Visibility filtering is a convenience, not the control. Server-side execution must independently refuse to run an agent carrying the admin action for a non-admin caller, with a clear error.
• The same refusal applies to workflows bound to such an agent.

Admin authoring experience

• When an admin adds the SimpleChat Admin action to an agent, show a confirmation notice in the agent modal explaining that the agent becomes admin-only from that point on.
• Show a persistent badge on any agent carrying the action so the restriction is visible at a glance, not only at the moment it was added.
• Show the same notice when a workflow is bound to an agent carrying the action.

Relationship to governance

This is a hard, built-in restriction that sits underneath governance rather than inside it. Governance can narrow access further; it can never widen it.

Governance already supports item-level policies for global_agent, global_action, and action types including global_action_type (application/single_app/functions_governance.py:39-56). The admin action should register as a governed action type so an admin can restrict it further — for example to a subset of admins in a multi-admin tenant — but the admin-only floor must hold even when no policy is configured.

Capabilities

The capability set needs its own audit as part of this work. Starting points to evaluate:

• Move make_group_inactive out of the general SimpleChat action, since it already requires Control Center admin access.
• Identify which other existing SimpleChat capabilities are really admin operations wearing a user-permission costume.
• Decide which genuinely new admin operations are worth exposing at launch, keeping the initial set small and defensible.

Acceptance Criteria

• A simplechat_admin action type exists with its own capability definitions, separate from the general SimpleChat action.
• The action type is filtered out of every non-admin-facing action listing and action picker.
• Agents referencing the action are filtered out of every non-admin-facing agent listing, catalog, and picker.
• Server-side execution refuses non-admin invocation with a clear error, verified independently of any UI filtering.
• An admin sees a clear warning when attaching the action to an agent, and a persistent badge on the agent afterwards.
• The action type is visible in the governance portal so admins can restrict it further, and governance cannot grant access below the built-in admin floor.
• Existing agents that do not use the action are completely unaffected.
• Route tests updated under functional_tests/route_tests/ for any new or changed endpoint and its auth policy.
• Functional tests cover: non-admin cannot list the action, cannot see an agent using it, and cannot execute it; admin can do all three.
• Documentation updated: feature doc under docs/explanation/features/, an action reference page under docs/reference/actions/, the governance admin doc, and docs/explanation/release_notes.md.

Open Questions

• Which capabilities ship in the admin action at launch?
• Should "admin" mean the application Admin role (admin_required), Control Center admin access (control_center_required), or either? These are distinct today in functions_authentication.py.
• What should happen to an agent carrying the action when a user's admin role is revoked while a session or scheduled workflow is active?
• Should group-scoped privileged operations key off group admin role rather than application admin?
• Does the restriction need to propagate to agent templates and any export/import path?

Notes

Depends on the capability audit in #1347, since at least one capability is expected to move between the two actions.

Primary files:

• application/single_app/functions_simplechat_operations.py
• application/single_app/semantic_kernel_plugins/simplechat_plugin.py
• application/single_app/semantic_kernel_loader.py
• application/single_app/functions_governance.py
• application/single_app/functions_authentication.py
• application/single_app/route_backend_agents.py
• application/single_app/static/js/plugin_modal_stepper.js
• application/single_app/static/js/agent_modal_stepper.js