Support pandas 3.0 in doctests

[ChristianGeng]

Summary

The docs/usage.rst doctest surfaced by audonnx#115 (the CI
action-version-bump rollout) fails under pandas>=3.0, unrelated to
that PR's diff.

Root cause: pandas 3.0.0 made a dedicated string dtype the default
(PDEP-14).
Per pandas' own migration guide:
"In pandas < 3.0, a Series of strings would have dtype: object, but
in pandas 3.0 the same code results in dtype: str." The failing run
installed pandas==3.0.5. Nothing about the actual output data
changed -- only how pandas 3.0 labels the column's dtype.

Fix

Sybil's DocTestParser for this file already runs with the ELLIPSIS
option flag (docs/conftest.py), so relaxing the assertion from
dtype: object to dtype: ... is enough -- it matches either
object or str (or whatever a future pandas release calls it),
without pinning pandas or adding version-conditional logic to the docs.

Test plan

• uv run pytest docs/usage.rst passes all 72 examples locally
  (previously 1 failed) under pandas 3.0.5
• CI passes on this PR

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Relaxes a doctest dtype assertion in docs/usage.rst so it remains valid under both pandas<3.0 (object dtype) and pandas>=3.0 (new string dtype), leveraging existing ellipsis matching.

File-Level Changes

Change	Details	Files
Relax doctest dtype expectation to be compatible with both legacy object string dtype and new pandas 3.0 string dtype.	Update the doctest-expected Series repr to replace the explicit dtype: object with a more flexible dtype: ... so Sybil’s ELLIPSIS option can match any string dtype label. Rely on existing Sybil DocTestParser configuration with ELLIPSIS flag instead of introducing pandas-version-specific logic or pinning pandas in docs tests.	docs/usage.rst

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[hagenw]

Can you claude somehow tell that it should stay within the 51 commit message limit for the names of the pull requests?