Two undeclared query keys hidden in the dead-key report's skip bucket: Get-PfbAlert -Flagged and New-PfbCertificateSigningRequest -Name

[juemerson-at-purestorage]

Two cmdlets send a query key the endpoint does not declare, in every published spec version
from 2.0 through 2.28. Both were found in the dead-key report's wire name unresolved skip bucket —
the report counts them but cannot evaluate them, so neither has ever appeared as a finding. The
resolver gap that hides them is #141.

Measured on main at 576eb12 against the 29 cached specs. Wire keys read from the source
assignment, not inferred from the parameter name.

---

1. Get-PfbAlert -Flagged — WRONG-RESULTS

Public/Alert/Get-PfbAlert.ps1:53:

if ($PSBoundParameters.ContainsKey('Flagged')) { $queryParams['flagged'] = ([bool]$Flagged).ToString().ToLower() }

GET /api/<v>/alerts declares exactly:

continuation_token, filter, ids, limit, names, offset, sort

No flagged, in any of 2.0 … 2.28. The name does appear in the /alerts path item — but only
under PATCH, as a request-body property. That is why Update-PfbAlert -Flagged is correct and
this is not, and it is a plausible route for how the parameter got here.

Consequence: Get-PfbAlert -Flagged $true silently returns every alert. The caller asked a
filtered question and got an unfiltered answer, with no error and no warning. Same class as the
other WRONG-RESULTS dead keys, but on a parameter whose whole purpose is filtering.

Route that works: the endpoint declares filter, so filter=flagged='true' is the supported
expression. Not verified live yet — that should precede any fix, since the operator syntax matters
and the spec does not settle it.

---

2. New-PfbCertificateSigningRequest -Name — CREATE

Public/Certificate/New-PfbCertificateSigningRequest.ps1:34 sends names.

POST /api/<v>/certificates/certificate-signing-requests declares no query parameters at all —
the operation's only entry is the X-Request-ID header, at both path and operation level, in every
version.

Same family as #101 and #106 Part 1, inverted: there a required names was omitted, here an
undeclared names is sent and ignored. Worth checking which identity the endpoint actually
expects before choosing a fix — dropping -Name is a breaking change for positional callers, so
this may be a body property rather than a query key.

---

Not findings, recorded so they are not re-derived

The quota family looked like four more instances and is not. New/Remove/Update-PfbQuotaGroup
and New-PfbQuotaUser expose -GroupId/-UserId, and the endpoints declare gids/uids rather
than group_ids/user_ids — but the cmdlets already send gids and uids. The apparent defect
came from inferring the wire key from the parameter name; reading the assignment cleared all four.
Noting it because the parameter names invite exactly that inference.

Ask

Decide the fix for each. They are independent — 1 is a read-path filter with a known supported
alternative, 2 needs the endpoint's real identity mechanism established first.