Add readonly and toolset request handlers

[kerobbi]

Summary

Adds support for /readonly, /x/{toolset} and /x/{toolset}/readonly.

Why

• Part of [WIP] Add HTTP mode. #1849

What changed

• Added context helpers for readonly mode, toolsets and tools
• Added withReadonly and withToolset route middleware
• Registered /readonly, /x/{toolset} and /x/{toolset}/readonly routes
• Added WithRequestConfig middleware to extract MCP headers into context and refactored InventoryFiltersForRequest to primarily read from context instead of headers
• Added tests for inventory filtering and header parsing

MCP impact

• No tool or API changes
• Tool schema or behavior changed
• New tool added

Prompts tested (tool changes only)

Security / limits

• No security or limits impact
• Auth / permissions considered
• Data exposure, filtering, or token/size limits considered

Tool renaming

• I am renaming tools as part of this PR (e.g. a part of a consolidation effort)
  • I have added the new tool aliases in deprecated_tool_aliases.go
• I am not renaming tools as part of this PR

Note: if you're renaming tools, you must add the tool aliases. For more information on how to do so, please refer to the official docs.

Lint & tests

• Linted locally with ./script/lint
• Tested locally with ./script/test

Docs

• Not needed
• Updated (README / docs / examples)

[Copilot]

Pull request overview

This PR adds support for HTTP route handlers that enable readonly mode and toolset filtering via URL paths (/readonly, /x/{toolset}, /x/{toolset}/readonly). It refactors the configuration extraction logic from directly reading headers to using context values, with route-based middleware taking precedence over header-based configuration.

Changes:

• Added context helper functions for storing and retrieving readonly mode and toolset configuration
• Introduced middleware to extract MCP-related headers into context and route-specific middleware for URL-based configuration
• Refactored inventory filtering to primarily read from context instead of headers, maintaining backward compatibility with header-based configuration

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 10 comments.

Show a summary per file

File	Description
pkg/context/request.go	New context helper functions for readonly and toolsets state management
pkg/http/middleware/request_config.go	New middleware to extract MCP headers into request context
pkg/http/headers/parse.go	New utility function to parse comma-separated header values
pkg/http/handler.go	Added route registration for readonly/toolset paths, route middleware, and refactored inventory filtering to use context
pkg/http/handler_test.go	Comprehensive tests for inventory filtering logic with various context and header combinations

[Copilot]

The WithToolsets function stores a slice directly in the context without copying it. If the caller modifies the slice after calling WithToolsets, it could lead to unexpected behavior or race conditions since the same slice reference is stored. Consider documenting that the slice should not be modified after being passed, or make a defensive copy of the slice before storing it in the context.

Suggested change

	// WithToolsets adds the active toolsets to the context
	func WithToolsets(ctx context.Context, toolsets []string) context.Context {
	return context.WithValue(ctx, toolsetsCtxKey{}, toolsets)
	// WithToolsets adds the active toolsets to the context.
	// The provided slice is defensively copied to avoid unexpected mutations.
	func WithToolsets(ctx context.Context, toolsets []string) context.Context {
	copied := append([]string(nil), toolsets...)
	return context.WithValue(ctx, toolsetsCtxKey{}, copied)