Evaluate whether some DB migrations need to invalidate FormCache

[sanason]

Touchpoints caches Form model objects to improve performance. The code invalidates a cached form whenever the Rails code updates the value of its fields in the underlying db representation. But there is nothing in place to invalidate the cache in response to database migrations. We should put something in place.

Example demonstrating why this matters

A recent PR added a logo_alt_text column to the forms table. After deploying this to production, we started seeing 500 errors reported in the log for the GET /touchpoints/{uuid}/submit endpoint. Here's an AI-generated recap of the issue:

• Symptom: ActiveModel::MissingAttributeError (missing attribute 'logo_alt_text' for Form) on GET /touchpoints/{id}/submit.
• Root cause: Stale Form objects cached in Redis (FormCache, 1-day TTL) from before the logo_alt_text migration ran. The DB was correct; the serialized cached objects had no logo_alt_text key, so reading it via Form#logo_alt_text_or_default raised the error without hitting the DB.
• Fix applied: surgically deleted the namespace:form-* keys from Redis via redis-cli --scan | xargs UNLINK.

The endpoint in question loads a hosted form for a user who wants to fill out the form. As long as these errors were occurring, users were not able to submit feedback through the forms in question and they were seeing an ugly error page when they tried to. There were over 100 forms in the cache - combined with a 1-day TTL, this could have been a serious glitch.

[afomi]

at least 2 options here:

1. force form cache revalidation in a follow-up migration, or one-off script (since cache wasn't considered in the recent PR)
2. add the app migration to the form cache key - which is a bit more robust - adding something like: ActiveRecord::Migrator.current_version in the form cache

cc @sanason