feat: add template versioning using tags

[dobrac]

This PR introduces the public API for managing template versions via Tags. It allows users to build templates with multiple aliases/tags and manage those tags post-build. It also updates the Sandbox.create method to support the template:tag identifier syntax.

Changes

1. Sandbox Initialization

Updated Sandbox.create to accept a scoped string identifier.

• Format: template-name:tag-name
• Default: If no tag is provided, the backend defaults to latest.

2. Template Building

Implemented a clean separation between the template alias and its associated tags during the build process.

• Supports passing a single string or an array/list of tags.
• Ensures that a specific build artifact can be referenced by multiple identifiers immediately.

3. Template Tagging

Added a utility to assign tags to existing builds.

• Syntax: Template.tag("template:tag", tags)

---

SDK Usage

JavaScript/Typescript

// 1. Create sandbox from tag
const sbx = await Sandbox.create("web-server:v1.0.2");

// 2. Build with multiple tags
await Template.build(tmpl, ["web-server:v1.1.0", "web-server:stable"]);

// 3. Update tags for existing build
await Template.assignTag("web-server:v1.1.0", "web-server:production");
// or
await Template.assignTag("web-server:v1.1.0", ["web-server:production"]);

Python

# 1. Create sandbox from tag
sbx = Sandbox.create("web-server:v1.0.2")

# 2. Build with multiple tags
Template.build(
    config, 
    names=["web-server:v1.1.0", "web-server:stable"]
)

# 3. Update tags for existing build
Template.assign_tag("web-server:v1.1.0", "web-server:production")
# or
Template.assign_tag("web-server:v1.1.0", ["web-server:production"])

---

Note

Introduces first-class template versioning via tags and template:tag identifiers across the API surface.

• New endpoints: POST /templates/tags to assign tags and DELETE /templates/tags/{name} to remove them; OpenAPI, server routes, and generated clients updated
• Build request changes: TemplateBuildRequestV3 now supports names (alias:tag list); alias deprecated; build flow propagates alias and tags
• Tag-aware usage: Handlers (sandbox create, template delete/update, build v2/v3, deprecated paths) now parse template:tag; health flag switched to atomic
• Caching: Template cache keys include templateID:tag; add targeted and all-tags invalidation
• Database: Migration adds env_build_assignments (env↔build↔tag), updates queries to join via assignments; snapshot upsert creates assignment; new CRUD for tag assignments
• Tests: Integration and DB tests for tagging, sandbox creation with tags, and snapshot behavior; specs and codegen updated accordingly

^{Written by Cursor Bugbot for commit 143316a. This will update automatically on new commits. Configure here.}

[linear]

ENG-3267 Migrate existing env_builds to m:n relation with ability to specify tags

[sitole]

Few questions

1. Are we okay and aware that when I specify template alias bob and alice, and then the alias for template bob called foo I will actually be able to retrieve it via bob:foooralice:foo`, is this expected?
2. When I use the flow you designed in TestTemplateTagAssignFromSourceTag - I think at some point I would love to reference not just template tag but specific template builds. This way i will be able to revert my production to any build in the past. Now I can only revert to versions that are somehow tagged, is that right?
3. In openspec for sandbox creation we have TemplateID that can actually be template id, alias or now id/alias with tag. What about updating the spec description or introducing a new field and deprecating the old one?

[dobrac]

Few questions

1. Are we okay and aware that when I specify template alias bob and alice, and then the alias for template bob called foo I will actually be able to retrieve it via bob:foooralice:foo`, is this expected?
2. When I use the flow you designed in TestTemplateTagAssignFromSourceTag - I think at some point I would love to reference not just template tag but specific template builds. This way i will be able to revert my production to any build in the past. Now I can only revert to versions that are somehow tagged, is that right?
3. In openspec for sandbox creation we have TemplateID that can actually be template id, alias or now id/alias with tag. What about updating the spec description or introducing a new field and deprecating the old one?

1. yes

2. you can reference them already, the select query already searches by the buildID

3. I agree with renaming, let's do that in another PR as it will change a lot of code