## Context

The Burner implementation is already both `EvelynIOUBurnerService` and `NenjimProcess`, but the service contract contains no domain operation: it exposes only duplicated startup and an implementation-specific stop lifecycle. The canonical `NenjimProcess` contract supports only Hub-owned `start()` and deliberately provides no common stop or restart.

## Goals / Non-Goals

**Goals:**

- Preserve `EvelynIOUBurnerService` as an empty typed component contract for Registry lookup and dependency injection.
- Keep startup exclusively on the implementation's `NenjimProcess` view.
- Remove public normal stop and the internal fields/helpers used only by that operation.
- Preserve immediate fixed-delay worker startup and cleanup if worker scheduling fails.
- Describe loss of process-local uncertainty state only across a complete process restart.

**Non-Goals:**

- No stop or restart addition to `NenjimProcess`.
- No Hub shutdown or worker-control API.
- No new external Burner domain operation.
- No transaction, polling, notification, dependency, or test behavior change.

## Decisions

### Keep an empty typed service view

The empty interface remains a `NenjimComponent`. This preserves the domain-specific type, Registry visibility, and future extension point without leaking Hub-owned lifecycle to consumers or exposing the concrete implementation.

### Retain only process startup

`EvelynIOUBurnerServiceImpl.start()` remains unchanged in responsibility and implements `NenjimProcess.start()`. The Hub already constructs and registers the same object, resolves it through `NenjimProcess`, and starts it through that view.

### Remove general stop state without weakening failed-start cleanup

Delete public `stop()`, its `stopping` flag, termination wait timeout, and interruption-aware stop helper. The `start()` scheduling failure path continues to call `shutdownNow()`, clear the worker reference, reset process-local state, and throw before startup succeeds. A successful process has no public stop/restart path until Nenjim defines one centrally.

## Risks / Trade-offs

- [A successful worker cannot be stopped through this implementation] → This is intentional; lifecycle expansion belongs in the common Hub/process architecture.
- [An empty service interface has no callable API] → It still supplies meaningful typed identity and prevents consumers from depending on implementation classes.
- [Operational recovery now requires process restart] → Document that restart forgets pending uncertainty state and requires external reconciliation first.

## Migration Plan

1. Recompile consumers against the empty service interface.
2. Remove direct Burner start/stop calls and select startup through the existing Hub process configuration.
3. Restart the complete process only after reconciling uncertain on-chain activity; no data or configuration migration is required.