Add Schedules.get_subscriptions_by_schedule to list a schedule's subscriptions

[ChrisJr404]

Motivation

Closes #1250. TSC wraps extract refresh tasks per schedule with get_extract_refresh_tasks(schedule_id), but there was no way to ask "which subscriptions run on this schedule?", which is what the issue asks for (monitoring the tasks in a schedule against a whitelist).

I went looking for a /schedules/{id}/subscriptions endpoint to mirror the extracts one, but the REST API doesn't have it. Subscriptions are only listable at the site level via Query Subscriptions, and each subscription already carries its schedule id. So this filters that list client side.

Behavior change

Adds one public method:

subs = server.schedules.get_subscriptions_by_schedule(schedule_id)  # -> list[SubscriptionItem]

It pages through the site subscriptions and returns the ones whose schedule_id matches, so on a busy site it costs one request per page. Nothing else changes. I put it on Schedules next to get_extract_refresh_tasks so the two task-listing calls live together. Because there's no server-side filter, this is a plain list, not a (list, PaginationItem) tuple like get(). Documented the per-page cost and the "no per-schedule endpoint" caveat in the docstring, and added a CHANGELOG entry.

Test plan

• test_get_subscriptions_by_schedule reuses the existing subscription_get.xml asset (its two subscriptions are on different schedules) and asserts only the matching one comes back.
• test_get_subscriptions_by_schedule_no_match asserts an unknown schedule id yields [].
• test_get_subscriptions_by_schedule_empty_id asserts an empty id raises ValueError, matching the other schedule methods.
• Full suite: 908 passed, 1 skipped. black --check and mypy clean.

One thing on trust rather than a regression test: I couldn't hit a live server, so the client-side-filter approach rests on the documented fact that Query Subscriptions returns every subscription with its <schedule id=...>, which the existing SubscriptionItem parsing already relies on.

[salesforce-cla]

Thanks for the contribution! Before we can merge this, we need @ChrisJr404 to sign the Salesforce Inc. Contributor License Agreement.

[jacalata]

Unfortunately subscriptions look different in Tableau Server (onprem) and Tableau Cloud, and don't have a schedule id on Cloud - that just means your method won't work for Cloud. I have a fix to at least handle the different shapes cleanly in #1875, but if you could add a docstring mention that this is Server only that would probably do. I can merge in my fix afterwards and check that it responds nicely to both kinds.
Tests look good, just need CLA signed.

[jacalata]

fix merge conflict (just keep both) and add a docstring saying this is Server only.

[Copilot]

🟢 Approval recommended

The focused implementation reuses existing pagination and subscription parsing, with no blocking issues identified.

No open issues 🎉

What changed in this PR

Adds a schedule-level subscription lookup using the existing site subscription API and pagination support.

Changes:

• Adds Schedules.get_subscriptions_by_schedule() to return subscriptions matching a schedule ID.
• Tests matching, unmatched, and empty IDs.
• Documents client-side filtering and per-page request costs.

File	Description
test/​test_schedule.py	Adds subscription lookup and input-validation tests.
tableauserverclient/​server/​endpoint/​schedules_endpoint.py	Adds the paginated, schedule-filtered lookup method.
CHANGELOG.md	Documents the new method and filtering behavior.

_{Review effort: Balanced}