Tilt at scale

Describe the Feature You Want

Native support for service grouping/stacking and auto-discovery from filesystem scanning.
Ideally:

• Services could be tagged with a group or stack label in their Tiltfile/resource definition
• tilt up --group=frontend would start all resources with that label
• Tilt could optionally auto-discover resources by scanning for Tiltfile or config files in subdirectories

Current Behavior

Currently, to start a subset of related services, users must either:

1. List all service names manually: tilt up service-a service-b service-c ...
2. Maintain shell scripts or wrappers that track which services belong to which groups
3. Use include() in the main Tiltfile but still manually register each subdirectory
   There doesn't appear to be a native way to:

• Tag resources with logical groupings
• Auto-discover resources from filesystem structure
• Filter tilt up by group/tag

Why Do You Want This?

Working with a monorepo containing ~40 microservices organized by domain. Common workflows:

• Start just the "frontend" services (5-8 resources)
• Start just the "backend-api" services (10-12 resources)
• Start a specific feature stack that spans multiple domains
  Currently building a thin wrapper tool that:

1. Scans for manifest files in the monorepo
2. Extracts a custom stack field
3. Calls tilt up with the filtered service list
   Would prefer to use native Tilt patterns if they exist or are planned.

Additional context
Add any other context or screenshots about the feature request here.

• Monorepo structure: /services/<domain>/<service-name>/Tiltfile
• Each service already has metadata files (similar to docker-compose.yml or manifest)
• Currently using include() in main Tiltfile but requires manual registration of each service
• Looked into local_resource for discovery but feels like a workaround

Start by examining the main Tiltfile patterns described in the issue, especially include(), local_resource, and the tilt up command. Define how resource labels, filesystem discovery, and group filtering should interact, then verify that a monorepo can start frontend, backend-api, and feature stacks without manual registration.