Data loss in cleanup_orphaned_tool_results with custom association

[bschmeck]

What this does

Following an error, the cleanup_orphaned_tool_results ensures that associations are properly built by comparing the tool call message's tool_calls to the foreign keys on the tool call message's tool results. We do this by plucking the ids of the tool calls and the tool call foreign keys of the tool call results. The name of the foreign key column to pluck is hardcoded as :tool_call_id, but a custom association may result in a different column name. In that situation, we wind up plucking the tool_call_id column from the tool_calls table, which is an identifier from the LLM provider, not a database id. There is guaranteed to be a mismatch, which results in tool calls and results being destroyed because they are incorrectly believed to be orphaned.

This change uses reflection to discover the name of the foreign key before plucking the column.

There is a single spec that demonstrates the failure, I'm happy to expand the test cases if there is interest in this change.

Fixes #583

Type of change

• Bug fix
• New feature
• Breaking change
• Documentation
• Performance improvement

Scope check

• I read the Contributing Guide
• This aligns with RubyLLM's focus on LLM communication
• This isn't application-specific logic that belongs in user code
• This benefits most users, not just my specific use case

Required for new features

• I opened an issue before writing code and received maintainer approval
• Linked issue: #___

PRs for new features or enhancements without a prior approved issue will be closed.

Quality check

• I ran overcommit --install and all hooks pass
• I tested my changes thoroughly
  • For provider changes: Re-recorded VCR cassettes with bundle exec rake vcr:record[provider_name]
  • All tests pass: bundle exec rspec
• I updated documentation if needed
• I didn't modify auto-generated files manually (models.json, aliases.json)

AI-generated code

• I used AI tools to help write this code
• I have reviewed and understand all generated code (required if above is checked)

API changes

• Breaking change
• New public methods/classes
• Changed method signatures
• No API changes

[bschmeck]

#515 fixes a similar class of bug in the same method.