feat: add foundation for resources and prompts registration

[patrickcping]

Change Description

This PR establishes a consistent foundation for registering tools, resources (both static and dynamic), and prompts within the MCP server. This refactoring sets up the necessary hooks and structure for future implementation of resources and prompts alongside the existing tools.

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update
• Refactoring (no functional changes)
• Test updates
• Chore (dependencies, tooling, etc.)

Key Changes

Registration Structure

• Refactored capabilities organization: Moved from internal/tools/ to internal/capabilities/ for better organization
• Added resource registration: Created capabilities/resources.go with RegisterResources(), RegisterStaticResources(), and RegisterDynamicResources() hooks
• Added prompt registration: Created capabilities/prompts.go with RegisterPrompts() hook
• Separated tool registration: Moved tool registration to dedicated capabilities/tools.go for consistency

Type Definitions

• Prompt types: Added PromptDefinition for future prompt implementations
• Resource types: Added StaticResourceDefinition and DynamicResourceDefinition for future resource implementations
• Validation types: Added DynamicResourceValidationPolicy to support validation for dynamic resources

Collection Interface Updates

• Updated Collection and LegacySdkCollection interfaces to include RegisterDynamicResources() and ListDynamicResources() methods
• Collections now support both tools and dynamic resources registration

Infrastructure

• Environment validation middleware: Comprehensive environment validator with caching for production environment protection
• Schema helpers: JSON schema generation utilities with UUID support and additional properties handling
• Test coverage: Added extensive test suites for middleware, validation, and registration

Initial Implementations

• Created placeholder implementations in capabilities/prompts/ and capabilities/staticresources/ directories
• These return empty lists and no-op registration functions, ready for future implementations

Related Issues

N/A - Foundation work for future features

Testing

• Unit tests (all existing tests pass)
• Integration tests (new validation middleware tests)
• Linting checks (make lint)
• Manual testing (server starts successfully)

Test Evidence

Commands Run

make test

Test Results Summary

All tests pass successfully:

• Total packages tested: 21
• Test status: All PASS ✓
• New test coverage: Added TestAllDynamicResourcesRegistered to validate resource registration

Key test packages:

• cmd: All command tests pass (logout, run, session)
• internal/capabilities: Registration and validation tests pass
• internal/capabilities/applications: All application tool tests pass
• internal/capabilities/environments: All environment tool tests pass
• internal/capabilities/populations: All population tool tests pass
• internal/capabilities/validation: All middleware validation tests pass
• internal/capabilities/filter: All filtering logic tests pass
• internal/capabilities/types: Type definition tests pass
• internal/errs: Error handling tests pass
• internal/sdk/legacy: SDK factory tests pass
• internal/server: Server initialization and filtering tests pass
• internal/tokenstore: Token storage tests pass

New test added:

• TestAllDynamicResourcesRegistered validates that all dynamic resources from individual collections are properly registered with the server

Full Test Output

go test -v -timeout 1m ./...
?       github.com/pingidentity/pingone-mcp-server      [no test files]
=== RUN   TestRootCommand
=== RUN   TestRootCommand/no_arguments
=== RUN   TestRootCommand/help_flag
=== RUN   TestRootCommand/invalid_flag
--- PASS: TestRootCommand (0.00s)
    --- PASS: TestRootCommand/no_arguments (0.00s)
    --- PASS: TestRootCommand/help_flag (0.00s)
    --- PASS: TestRootCommand/invalid_flag (0.00s)
PASS
ok      github.com/pingidentity/pingone-mcp-server/cmd  (cached)

[... Full test output continued ...]

=== RUN   TestAllDynamicResourcesRegistered
--- PASS: TestAllDynamicResourcesRegistered (0.00s)
=== RUN   TestAllToolsRegistered
--- PASS: TestAllToolsRegistered (0.00s)
=== RUN   TestAllToolsHaveSchemas
--- PASS: TestAllToolsHaveSchemas (0.00s)
PASS
ok      github.com/pingidentity/pingone-mcp-server/internal/capabilities        (cached)

[All packages pass successfully]

Breaking Changes

None - This is an additive change that maintains backward compatibility

Additional Context

This refactoring prepares the codebase for:

• Future static resource implementations (documentation, schemas, etc.)
• Future dynamic resource implementations (environment-specific resources)
• Future prompt implementations (interactive user prompts)

The structure follows the existing patterns established for tools registration and maintains consistency across the codebase.

[henryrecker-pingidentity]

Just a couple questions and a change to a few comments

[henryrecker-pingidentity]

Do we expect prompts not to be linked with a given collection?

[patrickcping]

At present, no, so I left this outside of a collection context. The reason being is that prompts are likely to act over a range of tools in different collections.
One thing to consider might be that we have virtual collections (e.g., a "monitoring" collection may invoke read tools from applications, populations and more)

[henryrecker-pingidentity]

Same question here - will these not be tied to specific collections?

[patrickcping]

I left static resources outside of collection context because this these could provide cross-tool (cross-collection) context, like specific documentation or guides. The dynamic resources are in a collection context because they are likely to be invoking an API call