feat(middleware): add concurrency_limit

[hidetzu]

Summary

PR 5/9 of the Phase 2 series. Adds the third and final defensive middleware: a global in-flight request cap using `golang.org/x/sync/semaphore`. Overflow is rejected immediately with `503` + `response.CodeServiceUnavailable`; requests do not queue.

Not wired into `app.New()`. PR 6 will insert `body_limit` + `rate_limit` + `concurrency_limit` into the chain in §6 order and add an end-to-end integration test, completing the defensive stack.

Key design decisions

`TryAcquire` (immediate rejection), not `Acquire` (queue)

`semaphore.Weighted` supports both. This middleware uses `TryAcquire` so overflowing requests get `503` instantly rather than blocking on a slot. Rationale: under load we want to shed traffic fast. Queueing hogs connections and delays client retry/backoff logic, and in the worst case compounds the overload. Phase 2 instruction §14 matches this choice ("超過時は 503") and explicitly says no `Retry-After` header is needed in Phase 2.

`maxInFlight <= 0` disables

Matches the convention established by `body_limit` and `rate_limit`. Useful for tests and opt-in no-limit local dev.

Parameter name `maxInFlight` (not `max`)

Go 1.21+ introduced `max` as a predeclared built-in; using `max` as a parameter name shadows it and `revive` flags it. `maxInFlight` is more descriptive anyway.

Test plan

6 tests, all race-clean:

Test	Verifies
`AllowsWithinCapacity`	`ConcurrencyLimit(2)` + 3 serial requests → all 200
`RejectsBeyondCapacityReturns503`	1-slot limit, one request in flight, second request gets 503 with standard error body (`code=service_unavailable`, non-empty message, correct Content-Type)
`RecoversAfterRelease`	After an in-flight request completes, the slot is actually returned so a subsequent request can acquire it
`MultipleSlots`	2-slot limit, 2 concurrent requests in flight both succeed, 3rd rejected
`DisabledWhenMaxZero`	`ConcurrencyLimit(0)` → 5 concurrent requests all pass (handler runs 5 times, confirmed via `sync.WaitGroup`)
`NegativeMaxDisabled`	`ConcurrencyLimit(-1)` → handler runs

The concurrent tests synchronize via a gate channel (`release`) + signal channel (`inHandler`) rather than `time.Sleep`, so the race detector sees clean ordering and the tests do not rely on timing.

Local checks

• `go vet ./...` clean
• `go test ./... -race -count=1` all pass
• `golangci-lint run` 0 issues (after renaming `max` → `maxInFlight` to avoid shadowing the built-in)
• `go mod tidy` leaves go.mod / go.sum clean

Dependencies added

```
golang.org/x/sync v0.20.0
```

Per `docs/development_rules.md` §3, an explicitly-allowed dependency for concurrency limiting.

Phase 2 context

#	PR	Status
1	response codes	merged
2	validation helpers	merged
3	body_limit middleware	merged
4	rate_limit middleware	merged
5	concurrency_limit middleware (this PR)	open
6	wire defensive middleware + E2E test	blocked on 3, 4, 5
7	analyze usecase adapter for pkg/prism	blocked on 1
8	/v1/analyze handler and routing	blocked on 1, 2, 7
9	/v1/prompt endpoint	blocked on 1, 2, 7

With this PR, all three defensive middleware will be complete and ready for chain wiring in PR 6. Intended to be squash-merged.