fix(api): classify bulk handler store errors instead of calling them all 500

[ericfitz]

Fixes #632.

The bug

Bulk handlers wrapped every store error in ServerError, discarding the
classification the store had already made:

HandleRequestError(c, ServerError(fmt.Sprintf("Failed to patch threat %s", patch.ID)))

ApplyPatchOperations returns a *RequestError carrying 400 patch_failed
for a patch document the client got wrong, and StoreErrorToRequestError
preserves it via errors.As — which is why the single-resource handlers were
always correct. The bulk handlers threw it away.

Verified against a running server, same threat and same pointer:

Route	Before
PATCH .../threats/{id}	400 patch_failed — "unsupported patch path: /nonexistent~field"
PATCH .../threats/bulk	500 server_error

Scope

The issue asked whether other */bulk handlers shared the cause. They do —
seven call sites across four files, which is also why the same CATS run
produced a 500 on repositories/bulk:

• threat_sub_resource_handlers.go — bulk patch
• asset_sub_resource_handlers.go — bulk create, bulk update
• repository_sub_resource_handlers.go — bulk create, bulk update
• document_sub_resource_handlers.go — bulk create, bulk update

All now route through StoreErrorToRequestError, matching the single-resource
handlers. It preserves an existing *RequestError, maps dberrors to
404/409/400, and still falls back to 500 for a genuine server fault.

Spec change this required

StoreErrorToRequestError returns ConflictError for dberrors.ErrDuplicate,
and none of the bulk operations documented 409. Without adding it, this fix
would have traded a Zero-500 violation for a documented-status-code violation.
409 (#/components/responses/Conflict) added to all seven operations, spec
revalidated, api/api.go regenerated. Version 1.6.1 → 1.6.2.

Test

TestBulkPatchThreats_ErrorClassification covers both directions, because a fix
that turned every failure into a client error would be equally wrong:

• a client error from the store surfaces as 400 with its own code intact
• an untyped store failure is still 500

Confirmed it is a real regression test by reverting the handler to the buggy
form — it fails there and passes on the fix.

Verification

make lint 0 issues · make build-server 1.6.2 · make test-unit 2448 passed,
0 failed · make validate-openapi 0 errors.

Not yet exercised against the cluster; that follows with the deploy.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WnrVyySuyJFqcMxB8q3pNc