[Reliability] Ack/Nack errors unhandled — messages double-processed or permanently stuck

[YHQZ1]

Both builder and deployer workers ignore the error return from msg.Ack() and msg.Nack().

If Ack fails after processing: the message is redelivered and the job runs twice — a user's deployment spins up duplicate ECS services.
If Nack fails after a bad parse: the message stays unacknowledged indefinitely and blocks the channel.

Affected:

apps/builder/internal/queue/worker.go:89 (Nack), 94 (Ack)
apps/deployer/internal/queue/worker.go:115, 130 (Nack), 120, 139 (Ack)

Fix:
go// BEFORE
m.Ack(false)

// AFTER
if err := m.Ack(false); err != nil {
log.Printf("failed to ack message %s: %v", m.MessageId, err)
}

Handle Ack errors in builder worker
Handle Nack errors in builder worker
Handle Ack errors in deployer worker
Handle Nack errors in deployer worker
Add structured logging on failures with message ID