fix: make the bash global lock actually exclude path mutations

[beardthelion]

Fixes #8.

Rebased onto main. The MCP half of this PR is gone: 03434cd fixed Manager.Close upstream while this was open, with the same remedy, so all that survives of it here is a test.

The bash global lock didn't exclude path mutations (f507fec). acquirePath sent on a per-path channel and acquireGlobal sent on a separate one, so the only thing the global lock excluded was a second bash. A bash command and a write to a file ran concurrently, which is the case the lock exists for. Replaced the two channels with one sync.RWMutex: a path mutation holds RLock for as long as it holds its path channel, bash holds Lock. Mutations still run in parallel with each other because readers do.

ed07d91 covers what the lock change itself could break rather than what it fixes: an exclusive lock on both sides would pass the bash-versus-write test while serializing every write in a batch, and Go parks new readers once a writer waits, which is a starvation shape nothing looked at.

1ffa940 adds a test for your Close fix. TestConnectDuringCloseDiscardsSession sets m.closed by hand and never calls Close, so deleting those three lines from Close leaves the whole internal/mcp suite green. The new test calls the real Close, asserts the flag, and polls two seconds for a restored session, and it is red against that same revert.

c2728e0 updates docs/concurrency.md, which still described bash taking the global channel this replaces.

What was measured:

check	before	after
bash + write concurrency	2	1
bash + bash concurrency (control)	1	1
different-path writes	3	3
121 calls with a bash mid-batch	n/a	finishes, bash runs
internal/mcp suite with the flag set removed from Close	green	red

Swapping acquirePath's RLock for Lock drops different-path concurrency from 3 to 1 and turns that test red, so it is not passing by construction.

One correction to the earlier version of this PR. I had claimed the acquisition order, gate before path channel, prevents a deadlock. It does not: bash only ever takes the gate and never holds a path channel, so no wait cycle exists either way, and the load test still passes with the order inverted. The code comment and commit message now say that instead.

Locally gofmt -s -l, go vet, golangci-lint, go mod tidy and the four cross-compile targets are clean, and the portable test set passes under -race -shuffle=on. TestAuthInferenceNetBYOKNoKey hangs on this machine for lack of network and does the same on an unmodified main, so I skipped it to measure; coverage with it skipped is 89.4% here against 89.3% for main.

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[atbe]

@beardthelion thanks for the contribution! could you back-merge main and make sure all CI passes?

[beardthelion]

Back-merged main and rebased. This is three commits on a3097f7 now and shows mergeable.

The MCP half is dropped: 03434cd fixed Manager.Close the same way while this was open. The only thing left from it is a test, since deleting those three lines from Close leaves the whole internal/mcp suite green and the new test is red against that revert.

CI has not run on this PR on any head yet. A fork PR needs a maintainer to approve the workflow run, so that one is on your side. Everything I can run locally is clean: gofmt, vet, golangci-lint, go mod tidy, govulncheck, the four cross-compile targets, and the portable test set under -race -shuffle=on.