Bug report: Master system cannot edit predefined context files for newly created agent

Steps

1. Log in to GoClaw Web UI as system (Master).
2. Open agent Fxxx:
   • Agent ID: 019dc854-xxxx-7ef7-xxxx-64bd4156xxxx
   • Agent key: fxxx
   • Agent type: predefined
   • Owner ID currently shown by API: 18xxxxxxxx
3. Open the agent Files tab.
4. Select predefined context files such as AGENTS.md, SOUL.md, IDENTITY.md, USER_PREDEFINED.md, or CAPABILITIES.md.
5. Try to edit/save the file.
6. Optionally attempt to update ownership through public API:
   • PUT /v1/agents/{id} with { "owner_id": "system" }
   • API returns {"ok":"true"}, but GET /v1/agents/{id} still shows owner_id: "18xxxxxxxx".

Expected

• A Master / gateway owner-level account should be able to administer and edit predefined agent context files, especially for an agent created/managed in the same system.
• If ownership transfer is unsupported through PUT /v1/agents/{id}, the API should reject owner_id with a clear validation error instead of returning success.
• There should be a documented, supported path to transfer ownership or allow system-level admin override.

Actual

• The Files tab is read-only and displays:

  Read-only — Only the agent owner can edit predefined context files.

• system (Master) is treated as non-owner for predefined context file editing.
• Sharing/admin role labels do not help because role-based permissions are documented as stored but not enforced.
• PUT /v1/agents/{id} accepts an owner_id payload and returns OK, but the owner is not changed.

Impact

• System administrators cannot fix or maintain predefined agent context files from the Master account.
• Newly created predefined agents can become effectively locked if the recorded owner_id cannot log in or does not map cleanly to the current Web UI identity.
• This creates a mismatch between admin expectations and actual permissions.
• The API success response for ignored owner_id updates can mislead operators and automation.

Proposed fix

1. Permission fix:
   • Allow gateway owner-level / Master users to edit predefined agent context files, or
   • Add a documented ownership transfer endpoint, e.g. POST /v1/agents/{id}/transfer-owner.
2. API contract fix:
   • If owner_id is immutable via PUT /v1/agents/{id}, return 400 Bad Request or 422 Unprocessable Entity when clients send owner_id.
   • Alternatively, support owner_id updates explicitly with proper authorization and audit logging.
3. UI fix:
   • Update the read-only logic/message to distinguish:
     • true non-owner users
     • shared users
     • Master/admin users
   • If Master override is allowed, show the editor instead of read-only mode.

Start with the Files tab logic that displays the read-only message and the PUT /v1/agents/{id} endpoint. Trace how Master users, agent owners, and owner_id updates are authorized and represented. Done means the supported permission or ownership behavior is consistent in the UI and API, with rejected unsupported updates reported clearly.