1. int64/uint64 query params -- Add fields with int64, uint64 types annotated with (sebuf.http.query) to test 64-bit query parameter handling. Add these to the ListResourcesRequest message (or create a new RPC with a request that has int64/uint64 query params).
2. float/double query params -- Add float and double query param fields.
3. Enum fields in messages -- Add an enum type (e.g., ResourceStatus) and use it as a field in request/response messages. The Resource message should have a status enum field.
4. Optional fields -- Add optional string and optional int32 fields to at least one message (e.g., add optional string description to GetResourceRequest or an optional field on Resource).
5. Nested messages -- The Resource message already has maps but add a nested message field (e.g., ResourceMetadata metadata_obj with sub-fields like created_by, version).
6. Repeated message fields -- Already has repeated Resource in ListResourcesResponse. Verify that's sufficient. Add repeated enum if missing.

Keep all existing messages and RPCs unchanged to avoid breaking existing golden files unnecessarily. ADD new fields/messages/RPCs for the missing coverage. Specifically:

• Add ResourceStatus enum with values: RESOURCE_STATUS_UNSPECIFIED, RESOURCE_STATUS_ACTIVE, RESOURCE_STATUS_INACTIVE, RESOURCE_STATUS_ARCHIVED
• Add ResourceMetadata message with fields: string created_by, int64 created_at_unix, int32 version
• Add status (ResourceStatus) and metadata_detail (ResourceMetadata) fields to the Resource message (use field numbers 7 and 8)
• Add optional string tag field to Resource (field number 9)
• Add int64/uint64/float/double query params to ListResourcesRequest (field numbers 5-8): int64 since_timestamp, uint64 max_id, float min_score, double max_score -- all with (sebuf.http.query) annotations
• Add a new RPC SearchResources(SearchResourcesRequest) returns (ListResourcesResponse) with GET method and path /resources/search that uses a request with a ResourceStatus status_filter query param (field number 1, query name "status") plus string query (field number 2, query name "q")

Do NOT change existing field numbers, message names, or RPC signatures. Only ADD new items.

CRITICAL: Fix-immediately policy. After expanding the proto, run ALL 4 generators' tests (not just httpgen). If the expanded proto reveals generator bugs (e.g., a generator crashes on int64 query params, fails to handle enum fields, or produces incorrect code for optional fields), you MUST fix those generator bugs immediately in this plan. Do not leave broken tests for later plans. The user decision is "Fix everything immediately: Every inconsistency found gets fixed in this phase." If fixes touch generator source files (generator.go, types.go, etc.), that is expected and acceptable. Document what was found and fixed. Run go build ./... to verify proto imports are valid. Then run ALL 4 generators' tests:

1. UPDATE_GOLDEN=1 go test ./internal/httpgen/ -run TestExhaustiveGoldenFiles -count=1 to update httpgen golden files.
2. go test ./internal/httpgen/ -count=1 to confirm httpgen passes.
3. UPDATE_GOLDEN=1 go test ./internal/clientgen/ -count=1 then go test ./internal/clientgen/ -count=1
4. UPDATE_GOLDEN=1 go test ./internal/tsclientgen/ -count=1 then go test ./internal/tsclientgen/ -count=1
5. UPDATE_GOLDEN=1 go test ./internal/openapiv3/ -count=1 then go test ./internal/openapiv3/ -count=1

If any test fails with a compilation error or generator crash (not just golden file mismatch), fix the underlying generator bug before proceeding. After fixing, re-run the full test suite. All 4 generators must produce valid output for the expanded proto. The canonical exhaustive test proto includes coverage for all scalar query param types (string, int32, int64, uint64, bool, float, double), enums in messages, optional fields, nested messages, and all existing features. All 4 generators handle the expanded proto without errors. Any generator bugs exposed by the expansion are fixed. Golden files are updated and all tests pass.