KeywordView Records

[Hanmac]

add KeywordView Records with only String parameters
so KeywordInstances can be turned into Views and Stored in CardStateView

this might help other stuff like #9806

[Hanmac]

@MostCromulent would such records in the CardStateView help with your Card Info Tooltip?

[MostCromulent]

@Hanmac - AI analysis is it's an architectural improvement but not functionally essential:

The tooltip in # 9806 follows this flow:

1. Gets CardStateView.getKeywordKey() -> a comma-separated string like "Flying,Haste,Protection from Blue"
2. Re-parses each token back into a KeywordInterface via Keyword.getInstance(token) in KeywordInfoUtil
3. Extracts getTitle(), getReminderText(), type params from those instances
4. Creates KeywordData objects (a simple value class with name, reminderText, typeParam)
5. Does additional processing: count annotation (Devotion, Affinity, Domain), keyword action extraction from oracle text, deduplication, sorting

Would KeywordView Records help # 9806?

Short answer: marginally, and it's not a prerequisite.

Benefits:

• Eliminates the round-trip of "keyword ->string -> re-parse to keyword ->extract display data." With records in CardStateView, structured data would be directly available
• For network play, the client currently can't extract reminder text without the full keyword parsing infrastructure. Records would provide that data pre-computed
• PR # 9806 already has KeywordData which is functionally identical to what a KeywordView record would be - this validates the concept

Limitations:

• The current Keyword.getInstance() re-parsing works reliably; the records would be a cleanliness improvement, not a bug fix
• Most of # 9806's complexity is in post-processing that happens after keyword extraction: count annotation (devotion/affinity/domain counts), keyword action scanning from oracle text, deduplication/merging, conjugation matching etc. None of that goes away with records.
• Adding records to CardStateView as trackable properties means touching the delta sync serialization layer (TrackableTypes) where keyword serialization is currently a TODO stub - that's non-trivial plumbing

Priority assessment

Factor	Rating	Notes
Benefit to # 9806	Low	Already works fine with string parsing
Benefit to netplay	Medium	Would enable proper keyword delta sync (currently stubbed)
Architectural cleanliness	Medium-High	Eliminates string -> instance round-trip, proper view separation
Implementation effort	Medium	Needs TrackableType implementation, serialization, migration
Risk	Low	Records are simple; main risk is in the serialization plumbing

Recommendation

This is a good independent improvement but not something # 9806 depends on.