Add Order Service — Place Order, CI/CD

[npcjake]

Closes #40, #43
Partial #41, #42

What's included

API endpoints (OrderService/)

• POST /api/orders — Place an order. Geocodes the delivery address via Nominatim, selects an available bot from BotNetApi, saves to Azure SQL, publishes a RobotOrderAssignment event to the robot-input Event Hub.
• GET /api/orders/{id} — Get order status by order ID.
• GET /api/orders?customerId={id} — Order history. customerId is formatted as "CustomerName:Phone" — whoever wires up the frontend history page will need to know this.

Infrastructure

• EF Core + Azure SQL (jacob-orderservice-sql2.database.windows.net / OrderServiceDb). Managed Identity auth — deliverybot-order-service is already granted db_owner. Schema is created automatically on first startup via Database.Migrate().
• Dockerfile (multi-stage, same pattern as BotNetApi)

CI/CD (.github/workflows/orderservice-deploy.yml)

• Triggers on push to main with changes under OrderService/**
• Runs unit tests → builds Docker image → pushes to deliverybotcr.azurecr.io → deploys to deliverybot-order-service Container App
• Event Hub connection string injected via GitHub secret at deploy time

Tests (OrderService.Tests/)

• Unit tests covering Place Order, Get Order, and Order History logic

Known gaps

#41 and #42 are partially complete. The endpoints exist, are fully wired up, and return real data — the skeleton is done. However, order status will always reflect what it was at placement (Pending or Assigned) because updating status requires consuming bot telemetry events from the Event Hub, which depends on the read model work (#64–#70). Once those events are being published, the Order Service will need a consumer to update order status to InTransit or Delivered.