Revise NDFrame.resample doc to reflect changes in #61985

[maread99]

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Tests added and passed if fixing a bug or adding a new feature
• All code checks passed.
• Added type annotations to new arguments/methods/functions.
• Added an entry in the latest doc/source/whatsnew/vX.X.X.rst file if fixing a bug or adding a new feature.
• I have reviewed and followed all the contribution guidelines
• If I used AI to develop this pull request, I prompted it to follow AGENTS.md.

@jbrockmendel, I believe this fixes a small oversight in necessary doc changes for #61985.

...sorry, the PR title should have been prefixed with DOC:

[jbrockmendel]

are you sure this is accurate? I think we special-case Day offsets to be tick-like in some circumstances.

[maread99]

I'm pretty sure the change is warranted for this specific context of NDFrame.resample. A call to this method ends up instantiating an instance of TimeGrouper (here) which in turn (since 3.0.0) raises a RuntimeWarning (here) if origin was passed although the frequency was in terms of days (i.e. non-tick).

So for

df = pd.DataFrame([1] * 5, index=pd.date_range("2026-06-02", periods=5))

this:

assert pd.__version__ == '2.3.3'
df.resample("3D", origin="2026-06-01").sum()

returns:

	0
2026-06-01 00:00:00	2
2026-06-04 00:00:00	3

whilst this:

assert pd.__version__ == '3.0.0'
df.resample("3D", origin="2026-06-01").sum()

raises:

RuntimeWarning: The 'origin' keyword does not take effect when resampling with a 'freq' that is not Tick-like (h, m, s, ms, us, ns)
  df.resample("3D", origin="2026-06-01").sum()

and returns:

	0
2026-06-02 00:00:00	3
2026-06-05 00:00:00	2

(The change came to my attention as I had a test that started failing with 3.0.0 precisely because it was assuming day as a tick frequency when resampling in this way).

[jbrockmendel]

thanks @maread99