Introduce concept of Coder, extract ActiveRecordCoder

[jeffcarbs]

Summary

FixtureKit currently only supports saving and loading fixture data from SQL (via ActiveRecord). As we look to support other data sources — for example, Redis or other non-SQL stores — we need an abstraction that allows different persistence strategies to plug in alongside the existing SQL behavior.

This PR introduces that abstraction with a Coder base class and extracts the existing SQL logic into ActiveRecordCoder as the first step.

What changed

• Adds FixtureKit::Coder, a base class that defines the coder interface:
  • observe — wraps fixture evaluation, allowing a coder to subscribe to writes as they happen (no-op by default)
  • save — encodes captured data into a persistable form
  • mount — decodes and restores previously saved data
• Adds FixtureKit::ActiveRecordCoder < Coder, which contains all SQL-specific logic previously spread across Cache and SqlSubscriber (now deleted)
• Cache delegates to ActiveRecordCoder and is otherwise unaware of SQL details
• Adds spec/unit/coders/active_record_coder_spec.rb with focused unit tests for the coder

What's next

Follow-up PR(s) will:

• Support multiple coders running simultaneously (e.g. SQL + Redis in one fixture)
• Allow consumers to register their own coders at runtime

🤖 Generated with Claude Code

[ngan]

Suggested change

	generate_statements(@captured_models + (parent_data ? parent_data.keys : []))
	@captured_models.merge(parent_data.keys) if parent_data
	generate_statements(@captured_models)

[jeffcarbs]

Eh, merge will mutate and it feels weird mutating the instance variable with provided args. Technically you could call this multiple times with different parent_data, and I wouldn't expect the first call to leak into the second.

I can update this in a similar way to be more readable though.