Implements item C of #1950: a configurable render-time policy for what
happens when `TemplateVariable.get(inputs)` is called against a template
that references a `{{field}}` not declared in the variable's
`inputs_type`. Closes the asymmetry Alex flagged on
`templates-and-composition.md:36` (composition warned, render path
silently substituted empty).

`template_mismatch_policy: Literal['warn', 'error', 'ignore']`:

- `'warn'` (default): emit a `RuntimeWarning` and render the missing
  field as the empty string (Handlebars' default behaviour).
- `'error'`: raise `TemplateInputsMismatchError` instead of rendering.
- `'ignore'`: render silently, no warning.

Configurable at three levels with explicit precedence:

1. Per-variable via `var()` / `template_var()`'s
   `template_mismatch_policy` argument. **Variable-level wins**, even
   when relaxing — set this when one specific variable should opt out
   of (or into) strict enforcement without affecting siblings.
2. Per-Logfire-instance via `VariablesOptions.template_mismatch_policy`
   or `LocalVariablesOptions.template_mismatch_policy`.
3. Falls back to `'warn'` when nothing is set.

The two options classes carry the field independently (they're peers,
not subclasses of each other), so a `LocalVariablesOptions`-driven
test/dev rig can be strict while production `VariablesOptions` stays
lenient (or vice versa).

`TemplateVariable._check_template_fields` runs every `{{field}}`
reference in the post-composition serialized value through
`pydantic_handlebars.check_template_compatibility` against
`get_template_inputs_schema()`. Any error-severity issue triggers the
policy.

For `'error'`, we raise a new `TemplateInputsMismatchError(Exception)`
rather than a `HandlebarsError`. The SDK's normal composition-failure
fallback (`Variable._resolve`'s outer `except Exception`) catches
HandlebarsError-and-friends to degrade gracefully to the code default;
the `'error'` policy is explicitly opt-in *loud* mode, so we route past
the fallback. A dedicated `except TemplateInputsMismatchError: raise`
in `_resolve` lets it escape to the caller.

`extract_template_strings` (previously `_extract_template_strings` in
`template_validation`) is promoted to public so the runtime check can
share the same JSON-walker the push-time validator uses; the function
is still small and dependency-free.

Eight new cases in `TestTemplateMismatchPolicy`:

- Default policy is `'warn'`, fires on mismatch, silent when inputs
  satisfy.
- Per-variable `'error'` raises `TemplateInputsMismatchError`.
- Per-variable `'ignore'` renders silently.
- Instance-level `'error'` raises.
- Instance-level `'error'` + variable `'ignore'` → renders silently
  (variable-level relaxes).
- Instance-level `'warn'` + variable `'error'` → raises (variable-level
  escalates).
- Instance-level `'warn'` + variable `'ignore'` → renders silently.

`'error'` mode raises `TemplateInputsMismatchError` (defined in
`logfire/variables/variable.py`), not `HandlebarsRuntimeError`. Three
spots referenced the wrong exception:

- `_internal/main.py` `template_var` `Raises:` clause
- `variables/variable.py` `TemplateVariable.get` `Raises:` clause
- `_internal/config.py` `TemplateMismatchPolicy` type alias docstring

Also clarify in `TemplateMismatchPolicy` and the field-level
docstrings that plain `var()` doesn't accept the policy — only
`template_var()` does. Plain `Variable` doesn't render `{{...}}`
templates so the policy doesn't apply.