feat: implement layer metadata endpoints for FeatureServer (#5)

[mikemcdougall]

Summary

Implements FeatureServer REST API endpoints for service and layer metadata retrieval as defined in Issue #5.

Changes Made

New FeatureServer Endpoints

• Service Metadata: GET /rest/services/{serviceId}/FeatureServer
  • Returns Esri-compatible service metadata including layer list, spatial reference, capabilities
• Layer Metadata: GET /rest/services/{serviceId}/FeatureServer/{layerId}
  • Returns detailed layer metadata including fields, geometry type, extent

Implementation Details

• Response Models: Complete Esri JSON schema-compatible models with AOT source generation
• Error Handling: Proper HTTP status codes (404 for missing resources, 500 for errors)
• Logging: Structured logging with event IDs for monitoring and debugging
• Integration: Uses existing ILayerCatalog abstraction for clean architecture
• Testing: Comprehensive integration tests covering all endpoints and error scenarios

Code Quality

• ✅ Builds with --warnaserror (warnings as errors)
• ✅ Follows established patterns from Admin/Health endpoints
• ✅ AOT-compatible JSON serialization
• ✅ Clean architecture (Server → Core abstractions only)

Test Plan

Added 10 integration tests covering:

• Service metadata response validates against Esri schema
• Layer metadata response validates against Esri schema
• Non-existent service returns 404
• Non-existent layer returns 404
• Invalid layer ID returns 404
• Wrong HTTP methods return 405
• Response content types and structure validation

Acceptance Criteria ✅

• GET /rest/services/{serviceId}/FeatureServer returns service info
• GET /rest/services/{serviceId}/FeatureServer/{layerIndex} returns layer info
• Response matches Esri JSON schema
• Fields, geometry type, spatial reference included
• Integration test: layer metadata response validates against Esri schema
• Integration test: non-existent layer returns 404

Architecture Impact

This is the foundational implementation for Phase 1 FeatureServer functionality. The metadata endpoints provide the schema information that will be required for:

• Query endpoints (Issue Query endpoint with WHERE clause parsing #6) - need field definitions for validation
• Output formatters (Issue Query output formats (Esri JSON, GeoJSON) #9) - need geometry type information
• Error responses (Issue Esri-compatible error responses #10) - use same response patterns

Notes

• Ready for query endpoint implementation (next phase dependency)
• Follows MVP plan Phase 1 priorities
• Uses test-driven development approach
• Maintains clean separation of concerns

[github-actions]

🤖 LLM Architecture Review

✅ Assessment: APPROVED

🏗️ Architecture Review Summary

⚠️ OpenAI Analysis Error:
Error calling OpenAI API: Error code: 429 - {'error': {'message': 'Request too large for gpt-4-turbo-preview in organization org-rf4P6tWUtUKBIeMU1oBdAkPn on tokens per min (TPM): Limit 30000, Requested 36362. The input or output tokens must be reduced in order to run successfully. Visit https://platform.openai.com/account/rate-limits to learn more.', 'type': 'tokens', 'param': None, 'code': 'rate_limit_exceeded'}}

💡 Fallback Recommendation:
Please configure OPENAI_API_KEY in repository secrets and ensure OpenAI credits are available.

Overall Assessment: NEEDS_ATTENTION (API Configuration Issue)

Falling back to basic static analysis...

---

Automated architectural analysis powered by OpenAI GPT-4
This review focuses on architectural patterns and design decisions
Human review still recommended for complex changes