feat(api): accept integer aliases as {id} path parameters (follow-up to #374)

[ericfitz]

Summary

Follow-up to #374. Now that integer aliases are exposed as a read-only field on every entity, the next step is to make the alias usable as a path parameter — clients can call GET /threat_models/7/diagrams/3 in place of full UUIDs.

Background

#374 deliberately scoped this out because tmi-ux #305's needs may be covered by client-side resolution (the client maintains an alias→UUID lookup map). Once tmi-ux begins using the new field, we'll know whether server-side path-param resolution is genuinely needed.

Specification

Implement a resolver middleware that runs before each parameterized handler. For each {id} path segment:

1. Try parsing as a UUID. If successful, pass through unchanged.
2. Otherwise try parsing as a positive integer. If successful, look up the entity by alias (scoped to the parent threat model for sub-objects) and replace the path parameter with the canonical UUID.
3. Otherwise, return 400 Bad Request.
4. If lookup returns no row, return 404 Not Found.

OpenAPI parameter schemas change from {type: string, format: uuid} to {oneOf: [{type: string, format: uuid}, {type: integer, minimum: 1}]} (or a string with a regex matching either).

Acceptance criteria

• All existing endpoints accept either a UUID or an integer alias for any {id} path parameter.
• Mixed UUID/alias paths work (e.g., TM by UUID + diagram by alias).
• 400 on malformed {id}.
• 404 on unknown alias.
• Integration tests cover the matrix.

Design references

• Spec: docs/superpowers/specs/2026-05-04-integer-aliases-design.md ("Out of scope" section)
• Plan: docs/superpowers/plans/2026-05-04-integer-aliases.md