[CDTOOL-1197] Use bulk purge for 'purge --key' requests

[rcaril]

Change summary

The PR modifies the 'purge --key' command to use the bulk purge API behind the scenes. This was a necessary change due to purge requests with spaces and other characters being serialized due to the nature of the POST /service/{service_id}/purge/{surrogate_key} endpoint.

Internal discussion on this can be found here:
https://fastly.slack.com/archives/C01E7FV8P5H/p1761241147473289

All Submissions:

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New Feature Submissions:

• Does your submission pass tests?

Changes to Core Features:

• Have you written new tests for your core changes, as applicable?
• Have you successfully run tests with your changes locally?

User Impact

This change will not apply any noticeable behavior to the end user. The commands responses will be identical.

Are there any considerations that need to be addressed for release?

Purge test file has been update to use variables instead of hard coding all test items.

[rcaril]

Test:

 make test TEST_ARGS="-run TestPurgeKey ./pkg/commands/purge" ok github.com/fastly/cli/pkg/commands/purge 1.064s 

[philippschulte]

Thanks for the fix — I appreciate the switch to the bulk purge endpoint to address key serialization issues. This is definitely the right approach for problematic keys (e.g., keys with spaces or slashes).

However, I’m concerned about one trade-off introduced here: since the bulk purge endpoint doesn’t return a status, we’re now hardcoding "Status: ok" in the CLI output. While this maintains compatibility with prior output, it may mislead users into thinking a purge succeeded when the key wasn’t actually purged.

I’m wondering if we could take a more dynamic approach here:

Detect whether the key is "safe" for the single purge endpoint by checking if key == url.PathEscape(key), and if so, use the original single purge API (/purge/) which returns real status.

Fall back to the bulk purge endpoint for keys that would be altered by encoding.

This would preserve the benefits of the existing implementation while retaining meaningful status for keys that don’t require escaping.

That said, I realize this adds complexity and potentially inconsistent behavior across keys, so I’m deferring the final decision to @kpfleming . If @kpfleming agrees that hardcoding Status: ok is acceptable then it should be clearly documented as assumed, not returned in the CHANGELOG.

[kpfleming]

Some small comments, otherwise the code looks good.