# Refactor: split DI registration to per-component extension methods

**Task**: AZ-314_refactor_di_registration_split
**Name**: Per-component AddXxxServices() extension methods in Program.cs
**Description**: Replace ad-hoc DI registrations in `Program.cs` with three extension methods, one per new csproj, matching the module boundary.
**Complexity**: 2 points
**Dependencies**: AZ-313
**Component**: API
**Tracker**: AZ-314
**Epic**: AZ-309

## Problem

`Program.cs` currently registers all services inline and ungrouped. After the split, the three Services csprojs have logically distinct registrations; co-locating each set with its csproj clarifies ownership and makes adding a new component easier.

## Outcome

- New extension methods in each new Services csproj:
  - `SatelliteProvider.Services.TileDownloader.TileDownloaderServiceCollectionExtensions.AddTileDownloader(this IServiceCollection)`
  - `SatelliteProvider.Services.RegionProcessing.RegionProcessingServiceCollectionExtensions.AddRegionProcessing(this IServiceCollection)`
  - `SatelliteProvider.Services.RouteManagement.RouteManagementServiceCollectionExtensions.AddRouteManagement(this IServiceCollection)`
- Each method registers exactly the services its csproj owns (concrete types + `IHostedService` registrations).
- `Program.cs` calls the three methods and removes the duplicated lines.
- DI container behavior is byte-equivalent (same lifetimes, same concrete types, same hosted services).

## Scope

### Included
- Three new `*ServiceCollectionExtensions.cs` files (one per csproj).
- Edit `Program.cs` to call them.
- Verify via integration smoke run that DI resolves end-to-end.

### Excluded
- Changing service lifetimes or replacing concrete types.
- Adding `IOptions<>` bindings that aren't already there.

## Acceptance Criteria

**AC-1: Each extension method exists and registers the expected services**
Given the post-refactor source
When inspecting each `*ServiceCollectionExtensions.cs`
Then it registers all services owned by its csproj and nothing else.

**AC-2: Program.cs uses extension methods**
Given `Program.cs` after refactor
When inspecting service registration block
Then `services.AddTileDownloader();`, `services.AddRegionProcessing();`, `services.AddRouteManagement();` appear and the previously-inlined registrations are gone.

**AC-3: DI graph unchanged**
Given the running app
When the smoke integration test profile is executed
Then it passes end-to-end (proving every required service still resolves).

**AC-4: Consumers updated**
Given the post-refactor source
When grepping consumers
Then all references to old service-registration code are removed.

## Constraints

- No service lifetime changes (Singleton stays Singleton, Scoped stays Scoped).
- Hosted services stay hosted services.
- DI registration order preserved where ordering matters.

## Risks & Mitigation

**Risk 1: Hosted-service registration order regression**
- *Risk*: `IHostedService` execution order is registration-order; an accidental reorder could change startup behavior.
- *Mitigation*: Inspect Program.cs Git diff carefully; keep the same call-site order in the three extension methods as in the original file.
