refactor: pass caller context into backend constructors

[abtreece]

Problem

Several backend constructors create their own context.Background() instead of accepting a caller-provided context.

Verified in:

• pkg/backends/acm/client.go:34
• pkg/backends/dynamodb/client.go:37
• pkg/backends/ssm/client.go:34
• pkg/backends/secretsmanager/client.go:39
• pkg/backends/imds/client.go:92
• Redis also creates background-derived contexts for internal connection/watch handling in pkg/backends/redis/client.go:141 and pkg/backends/redis/client.go:357.

These constructors then perform potentially blocking setup such as AWS config loading, credential retrieval, IMDS probing, table description, and client initialization.

Why this is a problem

Startup already creates a root context in cmd/confd/cli.go:473, and backend operations generally accept contexts. Constructors that use context.Background() cannot be canceled by the caller and do not naturally inherit startup deadlines or shutdown signals.

This is inconsistent with pkg/backends/awsutil.LoadAWSConfig, which already accepts a context and can respect cancellation/deadlines when the caller provides them.

Suggested refactor

• Add context-aware constructors for backends that perform I/O during initialization, e.g. New(ctx, ...).
• Thread the root startup context through backends.New.
• Keep compatibility wrappers if needed, but have them call the context-aware constructors with context.Background().
• Review Redis internal background contexts and tie long-lived watch/connection goroutines to an owned client lifecycle context where possible.

Acceptance criteria

• Backend initialization can be canceled by the top-level runtime context.
• AWS config loading and validation use caller-provided context.
• Tests cover constructor cancellation or timeout for at least one I/O-performing backend.
• Existing public constructor behavior is preserved through compatibility wrappers if necessary.