Decide what creating and stopping the core means, including a host that suspends it

[iderex]

The concurrency record in #9 answers what happens when the host process wants the
core's threads stopped. Nothing on this board builds that, and it is not the kind
of thing that gets added later, because by then every client has invented its own
version of it and the versions differ.

A phone suspends an application in the middle of a request and resumes it an hour
later on a different network. A television kills the process outright with a
queue half drained. A desktop keeps it running for a week across a suspend to
disk, which is the case where a clock that appears to have moved forward by
thirty seconds has actually moved forward by three days. All three are ordinary
and none of them is a crash.

What this produces

Creation as one act that takes every implementation the core wants from a client:
the storage in #40, the secret store in #33, the diagnostics sink in #100. What
happens when one of them is absent is already answered in each of those issues,
so this one states only that the absence is legal and that a capability a client
can ask about says which of them are present.

A stop that is true when it returns. Every request cancelled, every decode
stopped, no thread the core started still running, and nothing left half written
that #105 then has to reason about.

Suspend and resume as their own pair, distinct from stop, because a resume keeps
what a stop discards. What a resume may not assume is the part worth writing
down: not that the token is still valid, not that the network is the same one,
and not that the elapsed time is what the device's own clock makes it look like,
which is #102's question and is answered there rather than again here.

What a stop owes work that was never delivered. That is the durable queue in #47
and not a second mechanism built here, because two mechanisms for the same
promise means one of them is the one that gets tested.

Done when

A test creates the core with no client implementations supplied at all and proves
it works within the reduced capability each of those issues already states. A
test starts a set of requests, stops the core, and proves every one of them ended
in a cancellation or a named error, that no thread outlived the stop, and that
the stop returned only after both were true. A test suspends and resumes across a
clock jump and proves the core neither trusts the old token nor treats the jump
as elapsed time. Blocked on #9, #27, #33, #40 and #100.

[iderex]

The decision landed as docs/decisions/0115-creating-and-stopping-the-core.md, on bcd0744.

Creation is one call taking the byte store from 0040, the secret store from 0033 and the diagnostics sink from 0100, each of which may be absent, with a capability answer saying which are present. What each absence costs is decided in its own record and is not repeated.

Creation reaches nothing. No connection, no name resolved, no entry read out of the byte store, no secret read. That is the part worth deciding rather than inheriting, because a creation call that restored the last session is convenient in one place and wrong in four: it could fail for a reason unrelated to construction, it puts a store read and a network wait on whichever thread constructed the core, it makes the cold start in #46 depend on where the constructor was called, and it means a core somebody constructed and then decided against has already touched a keychain. Restoring a session is a call a client makes naming the session it wants, which is the shape 0033's store already needs since it cannot be asked what it holds.

Stopping fills in the three things 0009 explicitly left here.

The bound is a value the client may set, defaulting to two seconds, chosen so a stop called inside a platform's own termination callback returns while that callback still has time. The windows those platforms allow are stated in the record as a claim rather than a measurement, since nothing in this tree runs on a platform. There is a floor the bound cannot go below, and it is not a preference: 0009 already fixes that a decode runs to the end of its current step and that a read begun through the byte store completes, so a bound shorter than those cannot be met by any implementation and produces a stop that always reports failure, which teaches a client to ignore the report.

What a failed stop leaves is a core that is finished rather than restartable. It accepts no new work, and every call made after a stop was requested fails with cancelled from 0004 whether the stop succeeded or timed out. That kind is an imperfect fit and the record says so rather than growing the vocabulary: its meaning in 0004 is that the caller asked for this to stop, and what makes the reuse tolerable is that nothing but the client's own stop puts a core into this state. A restartable core is refused because it needs a rule for what survives a stop, per piece of state, and the honest list is long: the lanes, the capability answers, the correlator salt in 0071, whatever the transport was holding.

What a stop owes undelivered work is nothing beyond leaving it where it is. The queue in #47 is durable by construction, so a stop neither drains it nor discards it. A stop that tried to deliver would wait on a server, which the bound cannot hold, and a person closing an application on a train would wait for a network that is not there. A stop that discarded it would throw away somebody's actions at the moment they are least recoverable.

Suspend and resume are the separate pair this issue asks for. A suspend stops the core's own scheduled work, the recovery in #45 and the cadence in #57, cancels nothing the caller still wants, and flushes nothing because nothing is retained. A resume assumes none of the three things named here, and each has a concrete consequence rather than being a caution: the token is neither trusted nor refused locally, which is 0102's rule with 0005's rejection path already written for it; every connection the transport was holding is discarded, because a socket that survived a suspension onto a different network fails on its first byte and 0007 would read that as a slow server; and the clock jump is 0102's, named rather than answered again. A resume does no work of its own beyond restarting what a suspend stopped, since refreshing at that moment spends a person's connection while they are waiting to see something.

All three conditions here are untouched. Creating with no implementations and proving the reduced capability, stopping and proving every outstanding call ended with no thread outliving it, and suspending and resuming across a clock jump are statements about running code. There is no language chosen, no build and no test command in this tree, and #21 is open. This stays open on all three.