image_projections.params is written and read but never compared, so UMAP parameter changes do not invalidate the cache #76

Summary

projection_params() is serialized into image_projections.params on write (image_index_records_sqlite.py) and read back into ProjectionRecord.params, but nothing ever compares it. Cache staleness is decided only by scope_hash, which covers the model id and the accessible image-name set.

Consequence: changing any UMAP parameter — n_neighbors, min_dist, the metric, or the random seed — invalidates nothing. Every user keeps being served coordinates computed under the old parameters until their accessible image set happens to change, which for an idle gallery is never.

Why it matters now

PR #37 added a scope-hash short-circuit so an unchanged scope reuses the cached projection instead of recomputing. That makes this sharper: before, a request would at least recompute with the new parameters by accident. Now it provably will not.

Suggested direction

Either fold params into the staleness check (compare the stored string against projection_params(...) alongside the hash), or fold the parameters into scope_hash itself, or drop the column if it is genuinely only informational. The first is closest to the column's evident intent.

Note the argument-dependence: projection_params(n_points=...) varies with the point count, so a naive equality check would need to compare only the parameters that are not derived from the scope, or be evaluated at the same n_points.

Context

Found during adversarial review of PR #37 (reported as informational). Not a correctness bug today since the parameters are fixed constants — it is a trap for whoever first tunes them and finds the map unchanged.