Tracking: helper type detection improvements

[myitcv]

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

The helper conversion approach (introduced in #92) uses call-site-driven type detection to determine whether a helper produces structured YAML (CUE struct) or plain text (CUE string). Type signals have two confidence levels:

• Strong: determined by pipeline functions (e.g. quote → scalar, join → struct). These definitively constrain the helper's output type.
• Weak: inferred from YAML position (inline string, block scalar, etc.). Position tracking can be imprecise in complex templates.

When a helper is used in multiple call sites with different inferred types:

• Strong–strong conflicts produce an error (template is skipped).
• Weak conflicts (at least one side is position-inferred) emit a warning and proceed with first-encounter-wins.

The weak-conflict warnings surface cases where the converter's output may be incorrect for some call sites. In the integration test charts, these warnings appear for helpers like kube-prometheus-stack.namespace and common.tplvalues.render that are genuinely used in both struct and scalar YAML positions.

Describe the solution you'd like

This is a tracking issue for improvements to helper type detection. Potential directions:

• Dual-form helpers: generate both a struct and scalar form of a helper when conflicting contexts are detected, selecting the appropriate form at each call site.
• Variable usage analysis: when a helper is included via variable assignment ($x := include ...), analyse how $x is used to determine the type instead of relying on position defaults.
• Improved position tracking: reduce false weak-conflict warnings by improving isScalarContext precision in complex templates (nested control structures, block scalars with conditionals, etc.).

Describe alternatives you've considered

The current approach (warn on weak conflicts, error on strong conflicts) is a pragmatic balance. It avoids conversion regressions while surfacing ambiguities. No immediate action is needed — this issue tracks the known limitation for future improvement.

Additional context

See doc.go for the full helper conversion strategy. The helperTypeInfo struct in convert.go carries the confidence level. Integration test golden files (testdata/integration/*.txt) capture the current warnings.

[myitcv]

Progress update

Two improvements have landed on the fixes branch:

Condition context defaults to scalar. Helpers used in conditions ({{ if include "name" . }}) now default to scalar instead of struct. Helm conditions evaluate string truthiness — empty string is false, any non-empty string is true — so condition helpers almost exclusively produce bare strings like "true", not structured key-value pairs. This is implemented via an inCondition flag set during pipeToCUECondition and checked as a weak signal fallback in helperRequiredType.

Expanded doc.go documentation. The helper conversion strategy is now documented end-to-end: the fundamental ambiguity, why body-only analysis fails, annotated examples for each signal type, conflict detection semantics, scalar conversion tiers, known limitations, and future directions.

Future direction: Phase 0.5 global call-site consensus

The remaining ordering limitation — first-encounter-wins for weak signals, and more critically, a strong signal in a later-processed template being lost because an earlier weak signal already triggered conversion — can be addressed by introducing a Phase 0.5 between parsing and emission.

The full vision is a pre-emission walk of all templates that collects every call-site signal per helper and resolves types via a global consensus algorithm before any CUE is generated. However, there is a fundamental constraint: pipeline function signals (strong) are purely syntactic and can be extracted statelessly, but YAML position signals (weak) depend on the converter's state machine (blockScalarLines, inlineParts, the indent frame stack, etc.). Replicating this in Phase 0.5 would mean duplicating most of Phase 1's YAML processing logic.

A practical hybrid stepping stone:

1. Phase 0.5 collects only pipeline-based (strong) signals via a stateless AST walk.
2. Strong–strong conflicts fail immediately with cross-template diagnostics.
3. Any strong signal for a helper takes precedence — Phase 1 uses it directly, regardless of template processing order.
4. Only helpers with exclusively weak signals fall back to Phase 1's current state-machine-based inference.

This eliminates the most impactful ordering problem without needing to replicate the state machine. The weak-weak ordering issue remains but has smaller practical impact since both sides are already imprecise.

See doc.go for the full write-up.