Fix: -Limit ignored under AutoPaginate (#30)

[juemerson-at-purestorage]

Summary

• Invoke-PfbApiRequest -AutoPaginate had no running-total guard against the caller's -Limit: Purity//FB REST treats limit as page size only and keeps returning a continuation_token past that point, so every Get-Pfb* -Limit N call was silently re-paging the full collection.
• Adds a running-total check ($requestedLimit, read once from $QueryParams['limit']) that stops issuing further paginated requests once the total reaches the limit, and trims the final result to exactly that count.
• Follow-up hardening: tightened the limit guard to reject non-positive values, closing a latent GetRange() crash risk (unreachable via any current public cmdlet, but cheap to close).
• No cmdlet-surface change -- fix is entirely inside Private/Invoke-PfbApiRequest.ps1.

Fixes #30.

Test plan

• New Pester regression tests in Tests/Invoke-PfbApiRequest.Tests.ps1 covering: (a) pagination stops early and trims to -Limit when the server keeps returning continuation_tokens past that point, (b) full-collection auto-pagination is unchanged when no -Limit is given.
• Live-verified against a lab FlashBlade array (REST 2.26): a raw single-page request with limit=100 against a 340-item collection confirmed the server returns exactly 100 items and a continuation_token even though more items remain -- the exact root cause. Get-PfbSession -Limit 5 / -Limit 250 each returned exactly that many items with only one page request; Get-PfbSession with no -Limit still returned the full 340.
• Full unit test suite: 386 passed, 0 failed, 2 skipped -- no regressions.