Feat: Add support to Action Text enabled content

[chagel]

What this does

Improved the extract_content method to correctly process Action Text. When message model uses has_rich_text :content, message.content becomes ActionText:RichText, returning HTML tags unintentionally. Adjustments ensure only the desired content is extracted.

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

Quality check

• I ran overcommit --install and all hooks pass
• I tested my changes thoroughly
• I updated documentation if needed
• I didn't modify auto-generated files manually (models.json, aliases.json)

API changes

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

Related issues

[crmne]

Can you add some tests?

[chagel]

Can you add some tests?

@crmne Added basic tests and modified dummy app for instance double.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 86.18%. Comparing base (5156940) to head (2bc6e98).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #365      +/-   ##
==========================================
+ Coverage   86.16%   86.18%   +0.01%     
==========================================
  Files         118      118              
  Lines        5334     5334              
  Branches     1350     1351       +1     
==========================================
+ Hits         4596     4597       +1     
+ Misses        738      737       -1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[crmne]

Requesting changes for a couple of issues.

1. acts_as_message still does not work with a real has_rich_text :content model. The new path in MessageMethods#extract_content reads self[:content], but Action Text exposes rich text through content, while the raw attribute slot is still nil. When I reproduced this against a temporary has_rich_text :content message model on the PR branch, m.content.to_plain_text returned the expected text, m[:content] was nil, and m.to_llm.content came back empty. The new spec passes because it stubs message.[] directly instead of exercising a real Action Text-backed model.

2. Both extraction paths now coerce nil content to "" via to_s. That changes current behavior for persisted empty messages. RubyLLM::Message only normalizes nil to an empty string for assistant tool-call messages, but this patch makes plain persisted nil content come back as "" more broadly. I think we should preserve the existing nil semantics unless that change is intentional and covered by tests.

3. Minor: I would avoid hardcoding gpt-4.1-nano in the new spec. The model does not matter for this behavior, so I would prefer to use the default model and leave it unspecified.

[chagel]

Requesting changes for a couple of issues.

1. acts_as_message still does not work with a real has_rich_text :content model. The new path in MessageMethods#extract_content reads self[:content], but Action Text exposes rich text through content, while the raw attribute slot is still nil. When I reproduced this against a temporary has_rich_text :content message model on the PR branch, m.content.to_plain_text returned the expected text, m[:content] was nil, and m.to_llm.content came back empty. The new spec passes because it stubs message.[] directly instead of exercising a real Action Text-backed model.
2. Both extraction paths now coerce nil content to "" via to_s. That changes current behavior for persisted empty messages. RubyLLM::Message only normalizes nil to an empty string for assistant tool-call messages, but this patch makes plain persisted nil content come back as "" more broadly. I think we should preserve the existing nil semantics unless that change is intentional and covered by tests.
3. Minor: I would avoid hardcoding gpt-4.1-nano in the new spec. The model does not matter for this behavior, so I would prefer to use the default model and leave it unspecified.

@crmne Thanks for the thorough review. All three issues are addressed.