Support custom actions on native agentOS actors

Problem

The native RivetKit agentOS() actor currently exposes a fixed action surface implemented by the Rust actor plugin. Core AgentOs users, or custom JS RivetKit actors that own an AgentOs instance, can add arbitrary JS actor actions around the VM. Native agentOS() users do not have an equivalent way to attach app-specific actions while still using the native AgentOS actor lifecycle, persistence, and VM setup.

This blocks patterns like:

const vm = agentOS({
  // existing AgentOS config
  actions: {
    async syncWorkspace(c, input) {
      // app-specific actor code with access to ctx/db/services
    },
  },
});

Desired behavior

Allow callers to configure custom RivetKit actions on the AgentOS actor, e.g. agentOS({ actions: { ... } }), while preserving the built-in AgentOS native actions.

The custom actions should be regular JS/RivetKit actions that can use the actor context. Ideally they should also have a documented way to interact with the AgentOS VM when appropriate, without requiring users to reimplement the whole custom JS actor wrapper.

Notes / constraints

• Built-in AgentOS actions should remain reserved or collision-checked so app actions cannot accidentally shadow core actions.
• This should not require serializing JS callbacks into native VM config. The custom actions live at the RivetKit actor layer, not inside AgentOsConfigJson.
• This is different from JS VFS mounts/toolkits/etc.; those need in-process VM callbacks. This request is specifically for app-defined actor actions around the native AgentOS actor.

Why

This gives users an escape hatch for app-specific workflows without abandoning the native @rivet-dev/agentos actor and rebuilding a custom wrapper around AgentOs just to add one or two actions.

Start by tracing the native agentOS() entry point, the Rust actor plugin, and the AgentOs/AgentOsConfigJson boundary. Determine how RivetKit actions can wrap the native actor without serializing JS callbacks, then define how built-in action collisions are handled. Done means callers can register regular JS actions while native lifecycle, persistence, VM setup, and built-in actions remain intact.