Propagate pipe type constraints to #values schema

[myitcv]

Is your feature request related to a problem? Please describe.

When a Helm template uses a type-coercion pipe like .Values.replicas | int,
the converter emits int & #values.replicas in the output expression but
does not narrow the #values schema. The schema still uses the default
scalar type:

#values: {
    replicas?: bool | number | string | null
    ...
}

This means the schema is looser than it could be — it accepts values
that would fail the inline int & constraint at evaluation time.

Describe the solution you'd like

When the converter processes a pipe function that implies a type constraint
(int, int64, float64, toString, etc.), it should record that
constraint against the field reference and propagate it into the #values
schema. For example, .Values.replicas | int should produce:

#values: {
    replicas?: int
    ...
}

This would give better validation at the schema level and make the
generated CUE more self-documenting.

Describe alternatives you've considered

The current inline int & guard is functionally correct — CUE will
reject non-integer values at evaluation time regardless. The schema
improvement is about clarity and earlier validation, not correctness.

Additional context

The relevant code paths are:

• convertSubPipe() in convert.go processes pipe functions via their
  Convert callbacks but does not track type information.
• trackFieldRef() / buildFieldTree() / emitFieldNodes() build the
  schema from field references but only distinguish scalar vs non-scalar
  vs range-target — there is no per-field type constraint tracking.
• The pipe function definitions in helm.go (e.g. int, int64,
  float64) would need to signal their implied type so the converter
  can record it.