needs is now own-secrets, named for whose it is

It sat beside `secrets` — where a *provision's* credential lands on a consumer.
Both were name-to-path, both held something secret, and the names
distinguished them not at all. Reaching for the wrong one parsed cleanly and
failed somewhere else entirely, which is the shape of fault this whole design
exists to prevent, sitting in the manifest format.

The axis that separates them is not how secret they are — both are — but
whose. `secrets` is keyed by the provision it is for and belongs to a
relationship with another machine. `own-secrets` is keyed by a name the module
chose and belongs to nobody else.

A manifest using the old name is told the new one rather than refused with
"unknown field": whoever wrote it knew what they meant, and the mesh knows what
it is called now. An invented key is still refused as one rather than guessed
at.

Found by auditing the 19 manifest fields for whether any could be mistaken for
another. This was the only pair that could — and while checking it, a second
instance of the same collision turned up one layer down: `Manifest.Needs` and
`Resolution.Needs` were different concepts sharing a name in Go. The rename
separates those too.

cmd/mesh-control/plan.go

@@ -257,7 +257,7 @@ func declarationWith(ctx context.Context, open *stores, node string,
 	// per node, so a module running on three machines has three.
 	needed := map[string]map[string]string{}
 	for _, m := range plan.Modules {
-		for name := range m.Needs {
+		for name := range m.OwnSecrets {
 			sealed, err := inv.SecretForModule(ctx, node, m.Module, name)
 			if err != nil {
 				return nil, err