Nothing orders `start`, so a runtime dependency cannot be expressed at all

Split out of #43, which bundled three relationships under one depends_on. Two are now resolved on env-name-uniqueness: depends_on means lifecycle again, and data edges are inferred from {{exports.*}} rather than declared. This is the third, and it is untouched.

From the original report:

functions → supabase       the stack must actually be running to serve against

Ordering prepare does nothing useful here. What is actually needed is for supabase.start to have been invoked — and depends_on has no opinion about that, because nothing does.

start/stop are "a convention, made real by long_running" (crates/newgit/reference/definitions.md). They are invoked by hand, one at a time, with newgit action <resource>.start. So this is not depends_on failing to order starts. There is no start phase for it to order.

What exists today

• spawn runs prepare in bind order, and marks dependents blocked when a dependency's prepare fails.
• start is just an action name. Running it is the developer's or the agent's job, in whatever order they remember.

What is missing

• No newgit start [instance] bringing an instance's long-running resources up in dependency order.
• No way to say "my start needs yours to have started", as distinct from "my prepare needs yours to have prepared".
• No readiness notion. Started is not serving. A Supabase stack that has been exec'd is not the same as one that answers on its port, and ordering start commands without readiness just relocates the race rather than removing it.

That last point is why this did not get folded into the #43 work. Ordering starts is a morning's work; ordering them usefully means deciding what "up" means, which is a real design question.

Open questions

1. Is start orchestration in v1 scope at all? What To Defer Until v2 pushes command shims and hermetic builds out; this feels adjacent but not obviously the same class of problem.
2. If yes — is readiness declarative (a [ready] probe per resource: command, or TCP/HTTP against an allocated port), or is "the process is alive" enough? I suspect alive-is-enough is precisely the lie that produces flaky agent runs, which is the thing this project exists to avoid.
3. Does a runtime edge reuse depends_on — a start dependency probably does imply a prepare dependency — or is it a third key? #43 is a warning against overloading one key, but two keys that are almost always written together is its own kind of bad.

Filing as a question rather than a bug, same as #43: nothing misbehaves, there is simply no way to state the thing.

Start with crates/newgit/reference/definitions.md and the related issue #43, then inspect the existing spawn and newgit action <resource>.start entry points. Resolve whether start orchestration belongs in scope, what readiness means, and how runtime dependencies relate to depends_on; done requires an agreed design and documented behavior.