Distinguish hard CPU and memory limits from sampled resource budgets #5111

User Story

I use OpenShell across backends with different CPU and memory controls. I need to know whether a request provides a hard limit, reserves resources with a scheduler, or uses a watchdog that periodically checks usage and stops the workload when a budget is exceeded. I also need an explicit way to choose a sampled budget.

Problem Statement

Boolean CPU and memory capability flags do not explain how a backend enforces a request or which processes it covers. OpenShell also lacks a common request for periodically checked CPU-time and resident-memory (RSS) budgets.

A sampled watchdog can detect excess usage after it happens. It cannot provide the same guarantee as a hard limit.

Impact / Why This Matters

Users cannot compare backend guarantees or reliably request the enforcement they need. Treating a sampled watchdog as a hard aggregate limit would promise stronger enforcement than the runtime provides.

Unsupported requests should fail before changing runtime state. Callers should be able to choose a sampled budget explicitly and inspect its interval, precision and termination behavior.

Proposed Design

Expose resource enforcement kind and scope separately for limits and reservations. Add an explicit sampled CPU-time/RSS budget request and advertise sampling interval, precision and termination behavior. Validate independent axes before create, start or automatic restart changes runtime state. Budget-bearing SDK writes must first confirm gateway support, so an older gateway cannot silently discard the request. CLI template creation and gateway inspection expose the same guarantees.

Build on the typed CPU/memory requirements in PR #3012 rather than introducing a competing resource model.

Example workflow for review: When a driver offers only sampled RSS enforcement, a hard memory limit request is rejected. A caller may explicitly choose a sampled budget and inspect its interval and overshoot behavior instead; it must never silently become a hard-limit promise.

Acceptance Criteria

• A sampled watchdog never satisfies a hard aggregate CPU or memory request.
• Unavailable, unknown or changed negotiated guarantees are rejected before launch or lifecycle mutation.
• CLI and SDK budget writes fail before sending a mutation to a gateway that does not acknowledge the fields.
• Inspection distinguishes hard limits, scheduler requests and sampled termination, including scope and sampling limits.
• Resource values and guarantee descriptions remain consistent through CLI templates, gateway inspection and supported SDKs.

Alternatives Considered

Driver-specific JSON can express a budget but cannot make its guarantees discoverable or portable. Silently weakening an existing hard-limit request is unacceptable. Middleware, providers and interceptors do not own kernel resource enforcement.

Extend the typed resource shape from PR #3012. Use the existing typed resource model consistently across gateway, CLI and SDKs. Enforcement kind/scope, sampled budgets and acknowledgement checks are the additional scope.

Agent Investigation

No response

Checklist

• I've reviewed existing issues and the published docs
• This is a design proposal, not a "please build this" request