fix(nullplatform): fail template fetches that do not return 200

[jcastiarena]

What

Every template fetch in scope_definition, service_definition,
scope_definition_agent_association and parameter_storage_definition now
asserts status_code == 200 through a postcondition.

Why

A non-2xx response is not an error for the http provider, so a renamed or
missing template flowed on as if the response body were the template:
gomplate passed it through and jq died with

jq: parse error: Expected string key before ':' at line 1, column 4

four layers away from the file that caused it — that : is the one in
404: Not Found. The try(..., "{}") wrapped around response_body does not
help, because there was no error to catch.

Not hypothetical: nullplatform/scopes renamed kill-instances.json.tpl to
kill-instance.json.tpl, and since the branch defaults track a moving ref
(refs/heads/main), that broke the plan of an already-applied state with no
change in the caller's configuration.

After

Error: Resource postcondition failed

  with module.sd.data.http.action_templates["kill-instances"],
    │ self.status_code is 404

Fetch of https://raw.githubusercontent.com/nullplatform/scopes/refs/heads/main/k8s/specs/actions/kill-instances.json.tpl
returned HTTP 404, expected 200. Check that the action name is spelled as the
template file in the scope repository.

Verification

• Reproduced the 404 against the real repository: the postcondition fires and
  the message names the URL.
• Happy path unchanged: Plan: 5 to add, 0 to change, 0 to destroy, no
  postcondition triggered.
• pre-commit run --files on the four changed files: tofu-fmt,
  tofu-validate, tofu test, trailing-whitespace, detect-private-key all
  pass; commitlint passes on the commit.
• pre-commit run --all-files exits 1 on main before this branch:
  infrastructure/aws/vpc/main.tf and nullplatform/asset/ecr/main.tf are
  unformatted, and infrastructure/gcp/gke cannot resolve hashicorp/google
  under -lockfile=readonly. Confirmed on a pristine origin/main worktree, so
  it is not caused by this change. The four modules touched here validate clean
  in that same run (73 validated, 72 valid, the one failure being gcp/gke).

Not included

No test pins this behaviour: none of the four modules has a tests/ suite, and
adding one needs mock_provider "http" returning a chosen status_code plus a
mocked body that the downstream data.external (gomplate/jq) can survive. Worth
a follow-up rather than stretching this change.

[timossileandro]

ok