fix(httpapi): flaky activation scope assertion

[lux-liang]

Pull Request

Description

Fixes #1206.

The scoped /api/v1/status test searched the entire JSON response for the bare
digits 4711. A Unix timestamp containing those digits could therefore fail
the test even though the deployment-wide counter was correctly withheld.

This change matches a complete JSON numeric value instead. It still catches the
count if a projection exposes it under a renamed key, while ignoring the same
digits embedded in a larger timestamp.

Testing

• I have tested these changes locally
• I have added/updated tests that prove my fix is effective or my feature works
• All existing tests pass

Passing checks:

• go test ./internal/httpapi -run '^TestGetStatus_ActivationBlockIsOperatorOnly$' -count=50
• go test -race ./internal/httpapi -run '^TestGetStatus_ActivationBlockIsOperatorOnly$' -count=20
• go test ./internal/httpapi -count=1
• go vet ./internal/httpapi
• golangci-lint run --new-from-rev=HEAD ./internal/httpapi/...

go test ./internal/... was also attempted. The target package passed, while
unrelated environment-sensitive tests failed because the test host runs as
root (read-only-directory assertions), uses /var/log/mcpproxy, and did not
have the prebuilt E2E binary expected by internal/server.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[Dumbris]

Thanks for the fix, @lux-liang! Nice catch on the timestamp false-positive. I pushed a small follow-up commit simplifying the leak-check assertion to two plain assert.NotContains calls (matching the rest of the file's idiom) instead of the regex — no behavior change, just consistency.