Titanium SDK selection defaults to newest, breaking repeatable builds

Symptom

When building a Titanium project with the CLI, the build process frequently picks the most recently installed SDK even though the project’s tiapp.xml specifies a different <sdk-version>. This leads to build failures on CI pipelines that expect a stable, pinned SDK.

Constraints & Uncertainties

• The SDK Manager can install multiple SDKs, but project‑level selection defaults to the latest unless explicitly overridden.
• The CLI’s --sdk flag works, yet the <sdk-version> tag is ignored when the flag is omitted.
• Appcelerator Studio caches SDK paths in its preferences; after Studio updates or SDK reinstallations these paths can become stale, further confusing the selection.
• No official lockfile or pinning mechanism exists; developers rely on manual configuration or environment variables.
• The TI_SDK_HOME environment variable can override SDK selection, but its behavior varies across operating systems and is not consistently documented.

Goal

Determine a reliable method to pin a Titanium project to a specific SDK version so that builds are repeatable across local, CI, and Studio environments.

Unresolved Questions

1. Does the <sdk-version> tag in tiapp.xml enforce SDK selection when the CLI --sdk flag is omitted?
2. Is the TI_SDK_HOME environment variable consistently able to override Studio‑managed SDK paths on Windows, macOS, and Linux?
3. What mechanism, if any, can be introduced or leveraged to lock a project to a specific SDK version, ensuring repeatable builds?