Publish an owned node's app, or make it private again

The owner's exposure decision for ONE app (X16: public shares are Pro).

Only access, and deliberately not the daemon's second field. nerditd's PUT /api/services/{name}/share also takes consent: bool, which it requires (with, or instead of, a [deploy].edge_auth block) before it will accept public — its own guard against an operator publishing something by accident from a script. That flag is not re-exposed here, because on this path it would be a field whose only honest value is the one the caller already sent: reaching this route at all means an authenticated owner sent a same-origin, CSRF-bearing POST whose entire body is the word public, and the console puts a confirm dialog naming the app in front of it ("Anyone with the link can open <app>"). There is no accidental caller to protect. Forwarding consent unconditionally would be different and wrong — the route sends it only on public, where it means what the person did.

One shared service on one node, as the node itself reports it.

Every field but open_url is the daemon's answer passed through, because the daemon is the only holder of the share itself (D-P26-H1; the cloud keeps only who else may open a private one, ADR-W9): access is the stored exposure mode, state is the daemon's machine token for whether the share can serve now, and url is the address the daemon composed from the domain this cloud told it about. open_url is the one thing the cloud adds: where the owner's browser goes to be let in, which is a ticket this deployment mints and therefore a path on this deployment.