`dapr stop` and `dapr uninstall` report failure but exit 0, so scripts and CI cannot detect it

[Mukuwul]

Expected Behavior

When dapr stop fails to stop an app (or fails to parse a run template), the process should exit with a non-zero status code so shell scripts and CI pipelines can detect the failure.

Actual Behavior

There are three related defects in cmd/stop.go (checked at 96dd71a):

1. Per-app stop failures exit 0. The error branch prints failed to stop app id ... but never sets a non-zero exit code, so the command exits 0 (cmd/stop.go#L87-L94).
2. Run-file failures exit 0. Failed to stop Dapr and app processes is printed and the function plain-returns (cmd/stop.go#L60-L68).
3. With --run-file <f> -k, a template parse error is printed but execution continues into kubernetes.Stop with a zero-value config, and the -k branch then falls through into the local (self-hosted) process scan because it is missing a return (cmd/stop.go#L69-L77).

dapr uninstall has the same exit-code defect: Error removing Dapr: ... is printed but the command exits 0 (cmd/uninstall.go#L91-L95).

This mirrors the errors-must-be-detectable principle already established for output streams in #748.

Steps to Reproduce the Problem

$ dapr stop --app-id does-not-exist
❌  failed to stop app id does-not-exist: couldn't find app id does-not-exist
$ echo $?
0        # scripts/CI believe the stop succeeded

I have a fix ready and will open a PR right after filing this.

Release Note

RELEASE NOTE: FIX dapr stop and dapr uninstall now exit with a non-zero code when the operation fails.

[Mukuwul]

Fix is up in PR #1668 — makes all three dapr stop failure paths and the dapr uninstall failure path exit 1, and stops the -k run-file branch from proceeding on a parse error / falling through to the local process scan.