Functions v4 client: terminal/invalid-state control-plane ops surface opaque `2 UNKNOWN` (HTTP 400) instead of a meaningful status

[YunchuWang]

Summary

A Durable Functions v4 (durable-functions@0.4.x, gRPC-core) client calling a control-plane op (terminate/suspend/resume) on an instance in a terminal state (Completed/Failed/Terminated) currently gets an opaque 2 UNKNOWN: Exception was thrown by handler, which the compat turns into HTTP 400. v3 (extension-HTTP path) instead swallowed terminal-instance ops -> HTTP 200 (no-op).

Evidence (E2E run-2)

• Nonexistent instance -> 5 NOT_FOUND (rich detail) — handled in Add Functions gRPC core helpers #282.
• Terminal instance -> 2 UNKNOWN: Exception was thrown by handler (client sees NO detail). Host log shows Cannot <op> ... in the <State> state. but it is not propagated over gRPC.

Problems

1. Server-side: the extension's gRPC endpoint maps a wrong-state InvalidOperationException to opaque 2 UNKNOWN, losing the reason. Ideally return a meaningful status (e.g. FAILED_PRECONDITION) with detail — benefits ALL language SDKs.
2. Client-side (compat): without server detail, v4 can't distinguish terminal from other states without an extra getStatus round-trip; the current bare 400 is not ideal (should distinguish 404 nonexistent from a terminal/conflict status, and not be a plain 400).

Proposed direction (needs decision)

• Prefer a server-side fix (extension gRPC returns meaningful code+detail).
• Client interim: getStatus->runtimeStatus, then terminal (swallow->200 or 409/410) vs invalid-non-terminal (400 + Cannot <op> in <State>). Decide exact policy — reason this is separate from Add Functions gRPC core helpers #282.

Scope

3 e2e specs skipped in #282 pending this: suspend-completed, terminate-completed, terminate-terminated.