fix: prevent Orm.Connection() cached path from poisoning dbConfig

[goravel-coder]

Summary

• Orm.Connection() now resolves each connection's own database config from a shared, concurrency-safe QueriesCache, so Name()/DatabaseName() and connection-scoped behavior (like where the migration ledger row is written) reflect the requested connection instead of the default's.
• Concurrent Connection() calls that lazily build the same connection are now serialized by double-checked locking, eliminating the data race on the connection cache — TestOrmConnectionConcurrentSafe passes under -race and fails on the unlocked version.
• The exported database/orm/NewOrm constructor now takes a *QueriesCache built via the new NewQueriesCache(queries, dbConfigs) — breaking only for direct callers of the concrete constructor; contractsorm.Orm is unchanged, so no mock regeneration is needed.

goravel/goravel#987

Why

Orm.Connection() had a cached fast path that ignored the requested connection and reused the receiver's dbConfig. Once a non-default connection had been resolved, every later Connection() call for it returned an Orm whose Name()/DatabaseName() — and therefore derived behavior like where the migration ledger row gets written — still pointed at the default connection. Running two migrations on the same non-default Connection() wrote the second ledger row to the wrong database.

// app/database/migrations — two consecutive migrations on the same non-default connection
func (r *M20260826160940CreateUsersTable) Connection() string {
	return "sqlite"
}

func (r *M20260826161140CreateUserTokensTable) Connection() string {
	return "sqlite"
}

Before the fix, the second migration's ledger row was written to the sqlite connection, where no migrations table exists, failing the run. After the fix, both migrations run on their declared sqlite connection while both ledger rows are recorded on the default connection, matching Laravel's behavior.

The same fix hardens the connection cache for concurrent use. Lazy connection builds now flow through a shared QueriesCache guarded by an RWMutex with double-checked locking, so concurrent cold-path calls from different goroutines no longer race on the shared maps; Observe() snapshots the cache under a read lock before invoking user code. As a cleanup, the ambiguous internal cache field was renamed from m to connections.

// Concurrent resolution of the same lazily-built connection from multiple goroutines
var wg sync.WaitGroup
for range 10 {
	wg.Add(1)
	go func() {
		defer wg.Done()
		orm := facades.Orm().Connection("sqlite")
		// ...
	}()
}
wg.Wait()

Before the fix, these concurrent cold-path calls raced on the shared connection maps (a DATA RACE under -race). After the fix, double-checked locking serializes the build and every caller gets an Orm bound to the requested connection.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 72.37%. Comparing base (fda6f87) to head (875f806).
⚠️ Report is 1 commits behind head on master.

Files with missing lines	Patch %	Lines
database/orm/orm.go	0.00%	23 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1540      +/-   ##
==========================================
- Coverage   72.41%   72.37%   -0.04%     
==========================================
  Files         409      409              
  Lines       26475    26489      +14     
==========================================
  Hits        19172    19172              
- Misses       7301     7315      +14     
  Partials        2        2              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.