genpolicy: panics instead of erroring when an env var references a Secret that was not supplied

When a pod env var uses valueFrom.secretKeyRef and the Secret is not passed in (via --config-file or as a second document in the input YAML), genpolicy panics rather than returning an error:

$ genpolicy -y deployment.yaml
thread 'main' panicked at src/tools/genpolicy/src/pod.rs:901:13:
Couldn't get the value of env var: DB_PASSWORD
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
$ echo $?
101

The envFrom.secretRef form panics the same way at pod.rs:837. The message names neither the Secret nor the key, and nothing points at --config-file, so the first time you hit this it reads like a crash rather than a missing input. It is the tested behaviour since #10986 (tests/generate/main.rs::secret_in_separate_file asserts that exact string), so I assume the panic was a shortcut rather than a decision.

Minimal repro on main (caf233913): a Deployment with one container and

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-credentials
        key: password

Two things worth knowing when deciding what to do. Passing the Secret works, but the decoded plaintext value then lands in the generated policy, which becomes the pod annotation, so the secret is readable in the pod spec. And a Secret written with stringData instead of data panics at yaml.rs:393 before any lookup.

Two options I can see, and I'd rather ask than guess: (a) turn both panics into a proper error that names the missing Secret and key and points at --config-file, moving get_value/get_values to Result alongside the ConfigMap twin at pod.rs:826; or (b) an opt-in flag that emits a value wildcard for secret-sourced env vars that cannot be resolved, keeping the variable name in the policy but not the value. (a) seems uncontroversial; (b) loosens the policy so it should stay off by default. Happy to send a PR for whichever you prefer.