Update provider capabilities documentation with three-level hierarchy

[devin-ai-integration]

Update provider capabilities documentation with three-level hierarchy

Summary

Enhanced the "How to Add a Cloud Provider" documentation to clarify the three distinct levels of capabilities in the SDK and explain the complexity of instance type mapping. This addresses feedback that the capability system needed better explanation for new provider implementers.

Key changes:

• Restructured the "Capabilities: Be Precise" section with three clear levels:
  1. Provider-level capabilities - High-level API features declared in GetCapabilities()
  2. Instance type capabilities - Hardware-specific features as boolean fields on InstanceType
  3. Instance capabilities - Runtime state-dependent features for individual instances
• Added new section on Instance Type Mapping Complexity explaining the challenges of converting provider-specific data to v1.InstanceType format
• Added references to Lambda Labs implementation examples for each concept

Review & Testing Checklist for Human

• Verify capability level accuracy: Check that the three capability levels are correctly described by examining pkg/v1/capabilities.go, pkg/v1/instancetype.go, and internal/lambdalabs/v1/capabilities.go
• Validate Lambda Labs examples: Confirm that convertLambdaLabsInstanceTypeToV1InstanceType() in internal/lambdalabs/v1/instancetype.go actually demonstrates the mapping complexity I described
• Test documentation flow: Read through the updated section to ensure it integrates smoothly with existing content and provides clear guidance for new implementers

---

Diagram

%%{ init : { "theme" : "default" }}%%
graph TD
    HowToDoc["docs/how-to-add-a-provider.md"]:::major-edit --> CapabilitiesCore["pkg/v1/capabilities.go"]:::context
    HowToDoc --> InstanceTypeCore["pkg/v1/instancetype.go"]:::context
    HowToDoc --> LambdaCaps["internal/lambdalabs/v1/capabilities.go"]:::context
    HowToDoc --> LambdaInstanceType["internal/lambdalabs/v1/instancetype.go"]:::context
    
    CapabilitiesCore -.->|"Provider-level<br/>capabilities"| LambdaCaps
    InstanceTypeCore -.->|"Instance type<br/>capabilities"| LambdaInstanceType
    LambdaInstanceType -.->|"Mapping complexity<br/>example"| HowToDoc
    
    subgraph Legend
        L1[Major Edit]:::major-edit
        L2[Minor Edit]:::minor-edit  
        L3[Context/No Edit]:::context
    end

    classDef major-edit fill:#90EE90
    classDef minor-edit fill:#87CEEB  
    classDef context fill:#F5F5F5

Loading

Notes

This change was requested to improve clarity around the capability system after feedback that instance type mapping is "one of the trickier things" in provider implementation. The documentation now provides concrete guidance and examples for each capability level.

Link to Devin run: https://app.devin.ai/sessions/a811ba02cf8c45338aa1f6c1c8d6252e
Requested by: @theFong

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[theFong]

Instance capabilities are very similar to Instance Type capabilities but for a running instance vs type (template)

[theFong]

lets remove this section for now on instance type comlexity

[theFong]

technically true that they can be changed based on state (they are note, good thing to note). however what I'm referring to is some booleans like (stoppable) are replicated on the instance even though you can figure it out through the instance type thats correlated with it. Its redundant but important to remember they need to be accurate none the less. Take a look at the instance

[theFong]

lets remove IsContainer this because I dont want to highlight container capabilities.