Decide error-handling semantics for swallowed production errors (setTags, WriteAsyncJobMessage, setBucket, IAM policy)

[wz-gsa]

Context

The #551 lint burndown turned on whole-repo golangci-lint. Most errcheck findings were either fixed (trivial) or are test-only. But ~9 production errcheck findings represent a genuine product/behavior decision — should the failure fail the operation, or be best-effort log-and-continue? — that a senior dev who owns the provisioning flow should make, rather than an agent guessing. They are //nolint:errcheck // TODO(#556)-suppressed for now so the lint gate is green; this issue tracks resolving them.

The deferred sites

Location	Call	The decision
services/redis/delete_worker.go:66, :75	asyncmessage.WriteAsyncJobMessage	Highest priority. Silent failure = job-state drift: the customer sees success but the backend never recorded the state. Should this fail the worker / retry, or log?
services/rds/rdsinstance.go:169, :255	setEnabledCloudwatchLogGroupExports	Should a log-export config failure fail provision/modify, or be best-effort?
services/rds/rdsinstance.go:184, :237	setTags	Should a tagging failure fail provision, or be best-effort?
services/elasticsearch/elasticsearchinstance.go:197	setTags	Same question, ES path.
services/elasticsearch/broker.go:406	existingInstance.setBucket	Does a setBucket failure matter to the caller?
awsiam/iam_policy.go:401	(unchecked return)	Confirm the ignored error is safe or handle it.

Task

• For each site, decide fail-vs-log-and-continue based on the operation's semantics (esp. WriteAsyncJobMessage — job-state integrity).
• Implement real handling (return/wrap the error, or log with rationale).
• Remove the corresponding //nolint:errcheck // TODO(#556) comments.
• Verify golangci-lint run ./... stays green.

Split out of #551 so the low-risk lint cleanup can merge without embedding provisioning behavior changes an agent isn't confident making. Severity: MEDIUM (correctness/observability of provisioning + async job state).

[wz-gsa]

Landed on main via #556 (merged). The deferred sites carry //nolint:errcheck with a short reason (ticket number not in-code per repo convention). To find them all: git grep -n 'nolint:errcheck' -- 'services/**' awsiam/ — they're the production calls (setTags, setEnabledCloudwatchLogGroupExports, WriteAsyncJobMessage, setBucket, deleteNonDefaultPolicyVersions). Highest priority remains WriteAsyncJobMessage in services/redis/delete_worker.go (job-state drift). Remove each nolint as its handling is decided.