Support pre-flight validate method on models before method execution

Problem

When a model method like create is executed, it goes straight to the API call with no pre-flight checks. If the inputs are invalid (e.g. a VPC CIDR range that overlaps with existing VPCs, or a region that doesn't support a given droplet size), the user only finds out via a raw API error response that is difficult to interpret.

Real-world scenario encountered:

1. User configures a VPC with CIDR 10.116.0.0/24
2. Runs create method
3. DigitalOcean API returns a 422 with a JSON blob about overlapping ranges
4. User has to parse the raw error to understand the problem
5. This could have been caught before the API call by listing existing VPCs and checking for CIDR overlap

Proposed Solution

If a model defines a validate method, swamp should automatically call it before executing the requested method (e.g. create, update). This gives models a hook to run pre-flight checks against live API state.

How it would work:

• Model authors define an optional validate method on their model
• Before executing any other method, swamp checks if validate exists and runs it first
• If validate fails (throws an error or returns validation errors), the method execution is aborted with a clear error message
• If validate succeeds, the requested method proceeds as normal

Example use cases for validate:

• VPC: Check existing VPCs for CIDR overlap before creating
• Droplet: Verify the image slug and size are available in the target region
• Load Balancer: Verify the target tag exists and has matching droplets
• Firewall: Verify referenced load_balancer_uids exist

Scope of Changes

• Model execution engine — Add a pre-execution phase that checks for and runs a validate method before the target method
• Extension model contract — Document the validate method convention and what it should return (pass/fail with messages)
• Workflow engine — Ensure validation errors are surfaced clearly in workflow step output, distinct from execution errors
• Code generation — Auto-generated models could include common validation patterns (e.g. "does this resource name already exist")

This would catch configuration errors early with clear messages, rather than relying on raw API error responses after the fact.