Enable OTLP collector sidecar for non-Python agents (.NET, Java, TypeScript) in AgentCore Runtime

### Description

The AgentCore Runtime currently only starts the ADOT collector sidecar (listening on `localhost:4318`) when it detects `opentelemetry-instrument` in the container entrypoint — which is Python-specific. For .NET (and Java/TypeScript) agents that use the OpenTelemetry SDK directly to export OTLP over HTTP/Protobuf to `localhost:4318`, nothing is listening on that port, so telemetry is silently dropped.

### Current behavior

- **Python agents**: Runtime detects `opentelemetry-instrument` in entrypoint → starts ADOT collector sidecar on `localhost:4318` → telemetry flows to CloudWatch/X-Ray ✓
- **.NET/Java/TS agents**: Runtime does not start the sidecar → `localhost:4318` is unreachable → OTLP export silently fails → no telemetry in CloudWatch ✗

### Expected behavior

The ADOT collector sidecar should start for all agent containers regardless of language/entrypoint, accepting OTLP HTTP/Protobuf on `localhost:4318` and forwarding to CloudWatch (traces → X-Ray, metrics → CloudWatch Metrics, logs → CloudWatch Logs).

### Acceptance Criteria

- [ ] The ADOT collector sidecar starts on `localhost:4318` (HTTP/Protobuf) for containers with **any** entrypoint, not just those using `opentelemetry-instrument`
- [ ] .NET agents sending OTLP HTTP/Protobuf to `localhost:4318` have their traces appear in X-Ray via CloudWatch Transaction Search
- [ ] .NET agents sending OTLP HTTP/Protobuf to `localhost:4318` have their metrics appear in CloudWatch Metrics
- [ ] .NET agents sending OTLP HTTP/Protobuf to `localhost:4318` have their structured logs appear in CloudWatch Logs
- [ ] No code changes are required in the agent application — the standard `OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4318` convention works out of the box
- [ ] The behavior is consistent with what Python agents already get via the existing sidecar

### Additional Context

_No response_