feat: add configurable cpu/ram limits to k8s scope (CLIEN-781)

[fedemaleh]

Summary

• Adds optional cpu_millicores_limit and ram_memory_limit capabilities to the k8s scope spec so the Spin team can decouple Kubernetes resources.limits from resources.requests.
• Keeps ram_memory (request) at the top of the main form; both new fields live in the renamed Resources tab inside ADVANCED, alongside the existing cpu_millicores (request).
• Back-compat: build_context normalizes a missing/null limit to the request value via jq //=, so existing scopes render exactly the same resources: block as before.
• Validation: minimum: {"$data": "1/<request_field>"} rejects limit < request at the schema layer, reusing the precedent from health_check.period_seconds.
• Schema fields are added to required so the nullplatform UI actually renders them (rule from CLIEN-739: UI only renders required fields).

Spec: docs/superpowers/specs/2026-05-21-clien-781-memory-cpu-limits-design.md
Plan: docs/superpowers/plans/2026-05-21-clien-781-memory-cpu-limits.md
Ticket: https://nullplatform.atlassian.net/browse/CLIEN-781

Test plan

• bats k8s/deployment/tests/build_context.bats — 56 tests pass, including 5 new normalize_capability_limits cases (limit absent / null / explicit, both fields).
• bats k8s/deployment/tests/deployment_template_shape.bats — new structural test file, 5 cases asserting application container uses the right field for request vs limit, and that sidecars are NOT affected.
• bats k8s/deployment/tests/build_deployment.bats — no regressions.
• Manual gomplate smoke against the application container resources: block — explicit limits render verbatim; normalized null falls back to request value (1:1 with current production behavior).
• Manual UI smoke in a Spin dev environment once deployed — confirm the "Resources" tab shows CPU Millicores + CPU Limit + RAM Memory Limit, and that "Same as request" appears as the first dropdown option for RAM.