Adopt Dependency Injection architecture for OCR SDK package

**What**

Introduce Dependency Injection (DI) as a core architecture pattern for the OCR SDK Unity package to improve modularity, testability, and maintainability.

**Why**

The current package architecture can become tightly coupled as OCR features grow. DI enables clearer boundaries between services, easier mocking for tests, and safer feature evolution without large refactors.

**How**

* Define DI architecture goals and service boundaries for the OCR SDK package
* Identify core interfaces and abstractions for OCR services (networking, auth/session, access/subscription checks, configuration, logging)
* Introduce a composition root/bootstrapper for Unity runtime setup
* Refactor direct concrete dependencies to constructor or factory-injected interfaces where appropriate
* Ensure Unity-friendly lifecycle handling for injected services (scene transitions, initialization order, disposal)
* Add/update tests to validate behavior with mocked dependencies
* Document DI usage patterns and extension points for package consumers

**Acceptance Criteria**

* Core OCR SDK services are resolved through DI instead of hard-coded concrete dependencies
* Service contracts/interfaces are defined for major package components
* Runtime bootstrap/composition root is in place and documented
* Existing OCR flows continue to function after refactor
* Tests demonstrate mocking/substitution of dependencies
* Developer documentation explains how to register, override, and consume services

**Estimation**

**Dependencies**

None

Start by mapping the OCR SDK package's networking, auth/session, access/subscription, configuration, and logging services, then identify the Unity runtime bootstrap/composition root. Define interfaces and injection boundaries, preserve existing OCR flows, and validate them with mocked-dependency tests. Document registration, overrides, consumption, lifecycle, and extension points for package users.

Written by the indexing model from the issue text.