perf: Cache project identifier lookups

[matthewelwell]

GetFeature and GetSegment resolve their project on every call, purely to populate ProjectUUID — which the API never returns. For a caller working through many features in one project, that's a redundant request per entity.

This caches the immutable identifiers of a project (UUID and organisation ID) and the UUID→ID mapping, so each is fetched at most once per client.

GetFeature   2 requests → 1 after the first entity in a project
GetSegment   2 requests → 1

getProjectID is cached too, so CreateFeature, CreateSegment, UpdateSegment and GetTag benefit as well.

What is and isn't cached

Only immutable fields: a project's UUID and its organisation. GetProject and GetProjectByID stay uncached, so a caller reading a project after updating it still sees current values. That's the whole reason for the narrow projectRef struct rather than caching *Project.

Cache lifetime is the client's lifetime, with no invalidation. That's the right trade for a short-lived client (the Terraform provider builds one per plan/apply); a long-lived process would hold these until restart, which is safe precisely because the cached fields can't change.

Also exported

GetProjectIDByUUID, so callers that need a project ID before they have one — creating a feature, say — can resolve it without a round trip of their own.

🤖 Generated with Claude Code

[matthewelwell]

Closing: premature optimisation. GetFeature/GetSegment re-resolving the project on each call is a real redundancy, but not one worth caching for until it's measurably a problem — and caching brings a mutex and a staleness question with it.

If it does become worth doing, the right fix is probably upstream anyway: get-by-uuid could return the project UUID and remove the second request entirely, rather than us caching around its absence.