fix: add mutex lock in Info() ABCI method to prevent data race

[srpatcha]

Description

\Info()\ in \�aseapp/abci.go\ reads shared fields (\cms, ame, \�ersion) without acquiring \�pp.mu, while other methods like \InitChain()\ modify these fields under the mutex. This creates a data race.

Root Cause

The \BaseApp\ struct uses \�pp.mu\ to protect concurrent access to its fields. Methods like \InitChain(), \FinalizeBlock(), and \Commit()\ properly lock \�pp.mu\ before accessing shared state. However, \Info()\ — called by CometBFT during handshake and queries — reads \�pp.cms, \�pp.name, and \�pp.version\ without locking.

Fix

Added \�pp.mu.Lock()\ and \defer app.mu.Unlock()\ at the start of \Info(), matching the pattern used by other ABCI methods.

Testing

• Run the app with the Go race detector (-race\ flag)
• Trigger concurrent \Info\ calls during chain initialization
• Previously: race detector may report a data race. Now: properly synchronized.

Impact

Affects Cosmos SDK node operators. The data race is most likely during startup (when \InitChain\ and \Info\ may be called concurrently) and could cause reading inconsistent app state.

---

Closes #26321 (previous PR closed due to unsigned commits — this PR uses GPG-signed commits).

[greptile-apps]

PR author is not in the allowed authors list.

[srpatcha]

Hi maintainers, this PR is awaiting maintainer approval to run the GitHub Actions workflows (the action_required status on Checks/Changelog/Tests is the standard first-time-contributor gate). The single main check failure from April 24 was a GitHub API rate-limit hit on the semantic-pull-request action — not a code issue. Could a maintainer please approve workflow runs so the full CI suite can run? The PR fixes a data race in Info() ABCI method (mutex lock matching InitChain()/FinalizeBlock()/Commit() pattern). Thank you!