Feature/concurrent v1 v2 service mode

[freimer]

Summary

This changes Service Mode so queue-enabled deployments can serve both API versions concurrently:

• /api/v2/* remains the native queue-backed API
• /api/v1/executecommand is now available as a synchronous compatibility endpoint backed by the same queue worker
• queue_enabled = n still preserves the original standalone direct v1 behavior

This lets existing v1 integrations continue working while newer v2 clients use queue mode in the same service instance.

Problem

Historically Service Mode exposed either:

• v1 direct mode, or
• v2 queue mode

but not both at the same time.

That made queue-enabled deployments harder to adopt when existing consumers still depended on v1.

During local concurrency testing, this branch also uncovered and fixes a race where a queued v1 compatibility request could return 504 to the caller and still execute later once the worker reached it.

Changes

• Register /api/v1/executecommand alongside /api/v2/* when queue mode is enabled
• Route queue-enabled v1 requests through the same request queue used by v2
• Keep legacy direct execution unchanged when queue_enabled = n
• Share request validation / filedata preparation logic between v1 compatibility and v2
• Add synchronous waiting support for queued compatibility requests
• Expire timed-out queued v1 compatibility requests before execution
• Skip expired queued requests in the worker so late execution cannot occur
• Update service startup messaging and README to describe the new behavior

Testing

Ran locally without logging into Keeper:

• python3 -m unittest -q unit-tests.service.test_api_routes
• python3 -m unittest -q unit-tests.service.test_queue_concurrency
• python3 -m unittest -q unit-tests.service.test_service_manager unit-tests.service.test_service_config unit-tests.service.test_create_service unit-tests.service.test_config_operation

Added coverage for:

• queue-enabled route registration exposing both v1 and v2
• queue-disabled route registration preserving standalone v1
• queue-backed synchronous v1 compatibility behavior
• concurrent v1 and v2 requests sharing a single worker
• timeout/race handling so expired queued v1 requests do not execute later