tkn task sign adds empty 'resources: {}' to steps, causing strict decoding errors

Description

tkn task sign canonicalizes the YAML by marshalling through Go structs. This adds resources: {} to each step, which comes from the Kubernetes Container spec's Resources field being zero-valued.

When the signed task YAML is applied to a cluster, Tekton Pipelines rejects it with:

strict decoding error: unknown field "spec.steps[0].resources"

Tekton's Step type doesn't have a resources field — it's from the embedded Container struct but not valid in the Task API.

To Reproduce

cat > task.yaml << 'EOF'
apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: example
spec:
  steps:
    - name: build
      image: golang:1.26
      script: go build ./...
EOF

openssl ecparam -genkey -name prime256v1 -noout -out key.pem
tkn task sign task.yaml -K=key.pem -f=signed.yaml
grep 'resources' signed.yaml
# Output: resources: {}

kubectl apply -f signed.yaml
# Error: strict decoding error: unknown field "spec.steps[0].resources"

Expected Behavior

tkn task sign should omit zero-valued fields that aren't part of the Tekton API (like resources from the embedded Container spec), or use omitempty during marshalling.

Additional Context

There also appears to be a sign/verify roundtrip issue: signing a task with many annotations and then immediately verifying the output fails with invalid signature when validating ASN.1 encoded signature. This may be related to canonicalization inconsistency between sign and verify for larger YAMLs.

Environment

• tkn version: 0.45.0
• Tekton Pipelines: v1.12.0 (and all other LTS versions)
• OS: Linux (GitHub Actions ubuntu-latest)

/kind bug

Start at the tkn task sign entry point and trace the Go-struct YAML marshalling used for canonicalization, reproducing the task.yaml example. Compare the signing and verification canonicalization paths, then confirm completion by applying signed.yaml without the resources field and completing a sign/verify round trip for the larger annotated task.