Document Pager/Poller next_link type usage across spector tests

[Copilot]

Investigation

Analyzed all Pager and Poller implementations in spector tests to identify which use Url vs String for next_link continuation tokens.

Findings

Pagers: 1 uses String, rest use Url

String-based (continuation tokens):

• payload/pageable/pageable_server_driven_pagination_continuation_token_client.rs - all 6 functions use PagerState<String>

Url-based (standard pagination):

• All other ~15+ clients use PagerState<Url>
• Includes: azure/core/page, azure/core/basic, azure/payload/pageable, azure/resource-manager/, payload/pageable/

Pollers: All use Url

• All ~8 Poller implementations use PollerState<Url>
• Located in: azure/core/lro/, azure/resource-manager/

Pattern

Models serialize next_link as Option<String> for JSON. Implementation diverges at state machine level:

// Most implementations: parse to Url
continuation: next_link.parse()?,  // String -> Url
move |next_link: PagerState<Url>, pager_options| { ... }

// Continuation token only: keep as String  
continuation: next_token,  // String -> String
move |token: PagerState<String>, pager_options| { ... }

Continuation token pattern appropriately uses opaque strings; URL-based pagination uses typed Url objects.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[heaths]

I only wanted the analysis for design decisions and didn't intend for a PR to be opened.