feat: per-agent secret namespacing / isolation

Summary

The secret store is currently instance-level and global — all agents within a single spacebot instance share the same secret namespace. There is no access control or scoping at the agent level.

Problem

In multi-agent (or multi-tenant) deployments, a skill installed for one agent may expose credentials (e.g. a third-party API token) to other agents running in the same instance. Any agent that can invoke a skill or resolve a secret: reference can access any secret in the store, regardless of which agent it was intended for.

This is acknowledged in the source (src/api/secrets.rs):

// Secrets are global — shared across all agents in the instance.

Expected Behavior

Secrets should be scopable to a specific agent (or group of agents), so that:

• A secret configured for Agent A is not readable by Agent B
• Skills installed per-agent only have access to their own agent's secrets

Suggested Approaches

1. Per-agent secret namespace — prefix secrets with an agent ID (e.g. agent.<id>.APFY_TOKEN) and enforce namespace isolation at read time
2. Agent-scoped ACL on secrets — add an optional agent_id field to secret metadata; workers only resolve secrets matching their own agent ID (or unscoped secrets)
3. Separate secret stores per agent — store secrets under each agent's workspace directory

Option 1 or 2 would be the least invasive changes to the existing store interface.

Context

This becomes a real concern when multiple independent users share a single spacebot instance, each with their own agents and third-party service credentials.

Start by reading src/api/secrets.rs and tracing how secrets are stored, resolved, and accessed by workers or skills. Compare the proposed namespace and ACL approaches against the existing store interface, then define a scope that prevents one agent from reading another agent's secrets while preserving any intended unscoped access.