## Context

The Ticker implementation already combines two roles on one object: `TickerService` supplies domain queries and `NenjimProcess` supplies Hub-managed startup. The service interface redundantly declares startup and also declares stop even though the canonical process API exposes no stop operation. Internally, Ticker must still stop sources that were started before a later source makes startup fail.

## Goals / Non-Goals

**Goals:**

- Make the public Ticker service view lifecycle-free.
- Preserve the identical implementation object as both `TickerService` and `NenjimProcess`.
- Preserve complete reverse-order cleanup of sources started during a failed startup attempt, including suppressed stop failures.
- Preserve Hub startup, source activation, persistence, callbacks, and latest-price semantics.

**Non-Goals:**

- No stop or restart addition to `NenjimProcess`.
- No Hub shutdown or process-control design.
- No change to `PriceSource.start(PriceSink)` or `PriceSource.stop()`.
- No cleanup of unrelated service interfaces and no new automated tests.

## Decisions

### Keep startup only on the process view

Delete both lifecycle declarations from `TickerService` and retain `TickerServiceImpl.start()` solely as its `NenjimProcess.start()` implementation. `NenjimHubImpl` already returns the constructed implementation as `NenjimProcess`, registers the same object, resolves that process view, and invokes startup; no Hub wiring change is needed.

### Keep source stopping as private failed-start rollback

Delete the public `TickerServiceImpl.stop()` method but retain its existing private rollback path. On startup failure the implementation enters its internal stopping state, drains accepted callbacks, stops every source marked started in reverse registration order, resets its transient state, and reports stop failures as suppressed exceptions on the startup failure. This preserves resource safety without offering ordinary shutdown control.

The internal stopped state remains available after rollback so the existing failed-start retry behavior is not changed. A successful start has no newly introduced stop or restart path.

## Risks / Trade-offs

- [A successful Ticker has no public shutdown path] → This is intentional until common Hub/process stop semantics are designed.
- [Private state names still describe stopping] → They model rollback of `PriceSource` resources, not an exposed Ticker lifecycle operation.
- [Downstream source callers may have compiled against the removed methods] → Treat the service API removal as the explicit breaking change and retain the unchanged process startup route for the Hub.

## Migration Plan

1. Recompile consumers against the lifecycle-free `TickerService` contract.
2. Remove direct service-level startup or stop calls; runtime startup remains configured and performed by the Hub.
3. Roll back the software version if a consumer cannot yet migrate; no data or configuration migration is required.