Add extensions/workflows support for 3rd-party workflow discovery and execution

Summary

Add extensions/workflows/ directory support, similar to how extensions/models/ works for user-defined models. Extension workflows from 3rd-party sources should be dynamically discoverable via workflow search, executable via workflow run, and create proper .swamp/ folder structure for runs.

Motivation

Extension models already live in extensions/models/ and are dynamically loaded at CLI startup. There is no equivalent for workflows. Users installing extensions from 3rd-party sources need their workflow YAML files to also be discoverable and executable without manually copying them into .swamp/workflows/.

The extension manifest (extension_manifest.ts) already has a workflows: string[] field, but there's no runtime loading mechanism for extension workflows.

Design: Composite Repository Pattern

New Components

1. ExtensionWorkflowRepository — Read-only repository that discovers YAML workflow files from extensions/workflows/ (or configured directory)
2. CompositeWorkflowRepository — Wraps the existing YamlWorkflowRepository (primary/mutable) + ExtensionWorkflowRepository (secondary/read-only), implementing the WorkflowRepository interface transparently

Configuration

• workflowsDir field in .swamp.yaml (mirrors modelsDir)
• SWAMP_WORKFLOWS_DIR environment variable override
• Default: "extensions/workflows"
• Priority: env var > .swamp.yaml > default

Behavior

• Search: workflow search includes extension workflows alongside .swamp/ workflows
• Execution: workflow run works on extension workflows, creating runs in .swamp/workflow-runs/
• Read-only: Extension workflows cannot be deleted or saved via CLI commands
• Name conflicts: .swamp/workflows/ (primary) always takes precedence over extension workflows
• Backwards compatible: When directory doesn't exist, behaves identically to current behavior

Implementation Plan

Files to Create

• src/infrastructure/persistence/extension_workflow_repository.ts — Read-only YAML workflow repo for extensions dir
• src/infrastructure/persistence/extension_workflow_repository_test.ts — Tests
• src/infrastructure/persistence/composite_workflow_repository.ts — Composite wrapping primary + extension
• src/infrastructure/persistence/composite_workflow_repository_test.ts — Tests

Files to Modify

• src/infrastructure/persistence/repo_marker_repository.ts — Add workflowsDir?: string to RepoMarkerData
• src/cli/mod.ts — Add resolveWorkflowsDir() mirroring resolveModelsDir()
• src/cli/mod_test.ts — Add tests for resolveWorkflowsDir()
• src/infrastructure/persistence/repository_factory.ts — Add workflowsDir to config, widen workflowRepo type to WorkflowRepository, create composite in createRepositoryContext()
• src/cli/repo_context.ts — Resolve and pass workflowsDir to factory
• src/cli/completion_types.ts — Update WorkflowNameType to include extension workflows
• src/cli/commands/workflow_search.ts — Change type annotations from YamlWorkflowRepository to WorkflowRepository
• src/cli/commands/workflow_delete.ts — Guard against deleting extension-only workflows
• src/cli/commands/workflow_edit.ts — Handle editing extension workflows

Key Design Decisions

• No bundling needed: Unlike extension models (TypeScript), extension workflows are plain YAML — no compilation step
• No startup loading: Unlike models that register into a global registry at startup, workflows are loaded on-demand through the repository pattern
• Interface widening: RepositoryContext.workflowRepo changes from concrete YamlWorkflowRepository to WorkflowRepository interface (safe change, all call sites use interface methods)
• No changes to execution service: WorkflowExecutionService already depends on the WorkflowRepository interface, so the composite is transparent

Verification

1. deno check — Type checking
2. deno lint — Linting
3. deno fmt — Formatting
4. deno run test — All tests pass
5. Manual: Create extensions/workflows/ with a workflow YAML, verify search finds it and run executes it