feat: add list of builds per template

[dobrac]

Summary

Adds the ability to list all builds for a template via the GET /templates/{templateID} endpoint.

Changes

• Response schema:
  • Template fields (templateID, public, aliases, timestamps, etc.)
  • builds array containing complete build history
• Each build contains build metadata:
  • buildID - unique identifier for the build
  • status - current build status
  • createdAt, updatedAt, finishedAt - timestamps
  • cpuCount, memoryMB, diskSizeMB - resource configuration
  • envdVersion - version of the envd used

---

Note

Adds GET /templates/{templateID} to return a template with its paginated build history and introduces shared cursor-based pagination, updating schemas, handlers, DB queries, and clients.

• API/Spec:
  • New endpoint GET /templates/{templateID} with nextToken/limit to return TemplateWithBuilds (template + paginated builds).
  • Introduce reusable pagination params (paginationNextToken, paginationLimit) and apply to v2/sandboxes.
  • Split build schemas: TemplateBuild (metadata) vs TemplateBuildInfo (status/logs); update build-status endpoint to return TemplateBuildInfo.
• Handlers:
  • Implement GetTemplatesTemplateID to authorize, fetch template + builds via cursor, and set X-Next-Token.
  • Refactor GetV2Sandboxes to use new pagination utility.
• DB:
  • Add GetTemplateByIDWithAliases and GetTemplateBuilds (cursor on (created_at, id)), with generated sqlc code.
• Utils:
  • New generic pagination helper (NewPagination, ProcessResultsWithHeader) and export MaxSandboxID; add CastPtr.
• Types/Clients:
  • TemplateBuild now includes buildID (uuid), timestamps, resources; logging moved to TemplateBuildInfo.
  • Regenerate API types/clients/tests to reflect new endpoint, params, and schemas.

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

[linear]

ENG-3221 Add list of builds per template

[sitole]

I think use of uuidv7 can can help here a lot

[dobrac]

maybe, but only if we're generating them all from the database. Otherwise it's not guaranteed that the uuidv7 generated in one place is always preceeding uuid generated in another afaik

[sitole]

Yep, but as it's part of B-tree, I think it will still benefit from only local arrangements (because you insert newer UUID and then older) than reworking the whole tree because of UUIDv4 use.