fix(api): answer 404 for a public key outside the caller's namespace

[otavio]

What

GET /api/sshkeys/public-keys/{fingerprint} answers 404 instead of 500 when the key belongs to
another namespace.

Why

GetPublicKey resolves the key bounded to the caller's namespace, so a foreign fingerprint
matches no row and the store returns ErrNoDocuments. The method returned that error untouched,
and server/api/pkg/echo/handlers/errors.go maps a bare store-layer error to 500 — the handler
documents that case as one the service must fix.

UpdatePublicKey and DeletePublicKey already wrapped the identical read correctly, so this was
an inconsistency inside one file rather than a design gap.

Found while auditing an enterprise report of the same defect class on the firewall rule endpoint
(shellhub-io/team#220, private).

Changes

• sshkeys service: GetPublicKey maps ErrNoDocuments to ErrPublicKeyNotFound. 404 rather
  than 403 is deliberate: it does not disclose that the key exists in another namespace.
• tests: a case in TestGetPublicKeys pins the mapping.

Audit scope

I read every namespace-scoped service path in server/api/services. This was the only other
client-reachable instance. Already correct: devices, sessions, tags, access policies, SSH
identities, namespaces, members, API keys — each resolves the row and wraps the error before it
mutates. The remaining raw store returns are read-backs after a successful write, where 500 is
the right answer.

Testing

Create a public key in namespace A, then GET /api/sshkeys/public-keys/{fingerprint} with
credentials for namespace B. Expect 404, not 500.

[github-actions]

Claude finished @otavio's task in 49s —— View job

---

Code Review Complete

Reviewed 2 files across code quality, security, testing, language patterns, and architecture — no new issues found. The code looks good as-is.

A few notes worth recording (not blocking):

• The mapping is correct: NewErrPublicKeyNotFound carries ErrCodeNotFound, so the handler answers 404, and choosing 404 over 403 (no cross-namespace disclosure) is the right call.
• This implementation is actually more precise than the sibling reads it aligns with. UpdatePublicKey (sshkeys.go:199) and DeletePublicKey (sshkeys.go:254) map any PublicKeyResolve error to ErrPublicKeyNotFound, so a genuine store failure there would surface as 404. GetPublicKey now only maps store.ErrNoDocuments and lets real errors fall through to 500 — the correct distinction. Not something to change in this PR, but the two update/delete paths could later adopt the same errors.Is guard for consistency.
• The added test correctly pins the mapping and matches the existing mock conventions in TestGetPublicKeys.

---

To request another review round, comment /review.