userconfig: protect aliases map against concurrent access

[Pnkcaht]

What I did

• Protected the Config.Aliases map with a mutex.
• Made all reads and writes to aliases safe for concurrent use.
• Added minimal documentation explaining the concurrency guarantees.

Related issue

Fixes #1454

What was the bug

The Config.Aliases map was accessed concurrently without synchronization.

When multiple goroutines (or parallel tests) called methods like SetAlias, GetAlias, or DeleteAlias at the same time, this resulted in:

• fatal error: concurrent map writes
• flaky test failures in CI

Because Go maps are not thread-safe, even concurrent reads and writes could trigger panics.

Description

In the previous implementation, the Config struct exposed methods that mutated or read from the Aliases map without any form of synchronization.

When these methods were invoked concurrently—most notably from tests using t.Parallel()—the runtime detected unsafe concurrent access and crashed.

This change introduces a mutex inside Config and ensures that all accesses to the Aliases map are properly synchronized.

Result

• Alias operations are now safe for concurrent use.
• Flaky panics caused by concurrent map access are eliminated.
• No behavioral or API changes were introduced.

Validation — Reproducing the original failure

The issue was originally reproducible by repeatedly running the userconfig test suite, which intermittently failed with a concurrent map access panic.

Validation — Race detector

The fix was also validated using the Go race detector:

Validation — Full build

After the fix, the full test suite (go test ./...) runs successfully without failures.

[rumpl]

neat

[dgageot]

@Pnkcaht we have a concurrent.Map for that

[rumpl]

@Pnkcaht we have a concurrent.Map for that

The concurrent.Map can't be marshalled @dgageot