[Security hardening] Require explicit opt-in for workflow shell steps

## Summary

Workflow `shell` steps currently execute local shell commands from workflow YAML. This is a powerful and useful capability, but catalog-installed or downloaded workflows should make that execution boundary explicit.

## Why

A workflow definition can contain arbitrary shell commands. Users should have a clear prompt or policy gate before a workflow with shell execution runs, especially when the workflow came from a catalog, URL, or third-party source.

## Proposed direction

- Add a workflow-level permission such as `requires.permissions.shell: true`.
- Reject or pause before running shell steps unless the workflow declares the capability and the user opts in.
- Surface the exact command or a summarized command list before execution.
- Keep local/development workflows ergonomic, but make downloaded/catalog workflows visibly executable.

## Acceptance criteria

- Workflows with `type: shell` require an explicit declaration or opt-in.
- Existing bundled workflows without shell steps continue to run unchanged.
- Tests cover shell steps with and without the permission declaration.
- Documentation explains that shell workflows execute local code with user privileges.