Fix data races on entity/timer state and run tests with -race

[dansimau]

Summary

Running go test -race ./... surfaced ~25 data races from three root causes. This fixes them and enables the race detector in make test so they're caught going forward.

Root causes & fixes

• Entity.state (production). Written by the WebSocket reader goroutine (via StateChangeEvent) while read from automations, user code, and tests. Connection.mutex only serialized dispatch — not the entity's own public field. Now guarded by a sync.RWMutex in GetState/SetState/GetID. All entity subtypes (Light, BinarySensor, InputBoolean, …) embed *Entity, so they're all covered.
• Timer.running/timer/ctx (production). Mutated by the clock.AfterFunc callback goroutine concurrently with StartContext/Cancel/IsRunning. Now guarded by a sync.Mutex, released before invoking the callback fn to avoid re-entrancy deadlocks.
• Test-local bool flags in connection_metrics_test.go, written inside automation actions and read from the test goroutine. Converted to atomic.Bool (matching the existing atomic.Int32 pattern in TestLoopProtection).

Makefile

go test now runs with -race. Added SHELL := /bin/bash and set -o pipefail so a detected race actually fails the build instead of being swallowed by the pipe into the colouriser.

Verification

• go test -race -count=1 ./... clean across 3 fresh runs.
• make test passes end-to-end (coverage gate at 63.4%) and now exercises the race detector.
• gofmt / go vet clean on the touched files.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8b951e5262

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[dansimau]

Thanks — good catch on make test going red under -race. Fixed in 2b9f80d.

Root cause: the failure wasn't a data race per se — it's the classic SQLite :memory: gotcha. In-memory databases are scoped to a single connection, but database/sql keeps a connection pool. The migration creates the logs table on one connection; a query that lands on a different pooled connection sees a fresh empty database → no such table: logs. -race shifts scheduling so the pool is more likely to hand out a second connection, which is why it surfaced there.

Fix: store.Open now pins in-memory DSNs to a single connection (SetMaxOpenConns(1)), so the whole Store shares one in-memory database. File-backed DBs keep the default pool (WAL still allows concurrent readers).

While in here I also fixed a couple of other things -race shook out on repeated runs (go test -race -count=3 ./...):

• A real data race on the shared default logger's stopChan (written under lock in Start, read without the lock in pruneLogs/Stop).
• TestTimer's flag was written in the callback goroutine and read in the test goroutine without synchronization (now atomic.Bool).
• The metrics tests used fixed time.Sleep before asserting, which could flaky-fail under the slower race build — switched to WaitFor polling.

make test and go test -race -count=3 ./... are both green now.