Support the $TAG record accessor in processor/filter condition rules

[zshuang0316]

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

Processor and filter condition rules cannot match on the record's tag.

The record accessor already understands $TAG / $TAG[n], and conditions
accept record-accessor patterns for record/metadata fields. But the condition
evaluator calls flb_cfl_ra_translate() with a NULL tag
(src/flb_conditionals.c, evaluate_rule()), so any rule referencing $TAG
resolves to nothing and silently never matches. There is no error — the rule
just always evaluates false, which is surprising given $TAG works elsewhere.

Concretely, this does not work today:

    processors:
      logs:
        - name: content_modifier
          action: insert
          key: tier
          value: frontend
          condition:
            op: and
            rules:
              - field: "$TAG"
                op: regex
                value: "^app\.frontend\..*$"

Describe the solution you'd like

Allow condition rules to reference $TAG by making the chunk tag available to
the condition evaluator, so a processor/filter can select records by tag inline
(e.g. to consolidate several tag-routed streams into one output without an
extra routing hop).

I put together a reference implementation in #12090 (draft) that threads the
chunk tag through the evaluation path (flb_condition_evaluate[_ex],
flb_mp_chunk_cobj, the processor and filter callers; the router keeps passing
NULL since it routes by tag natively) and adds unit coverage. I opened it
mainly to make the design concrete for discussion, not as a finished proposal —
happy to change the approach.

Questions for maintainers:

1. Is enabling $TAG inside processor/filter conditions a direction you'd
   accept, or is matching-by-tag intended to stay solely at the routing layer
   (Match, routing conditions)?
2. If yes, is threading tag/tag_len through flb_condition_evaluate* the
   preferred shape, or would you rather the tag be carried some other way
   (e.g. on an existing context struct) to avoid the signature change?

Describe alternatives you've considered

• rewrite_tag + separate pipelines / Match selection — works, but forces
  pipeline fan-out for what is conceptually a single conditional processor step.
• Routing-level conditions — select at the router, not within a processor, so
  they can't gate an in-place processor action on the tag.

Additional context

Use case: several inputs land under different tags and need a single processor
action applied only to a subset selected by tag before sharing one output.
Today that requires restructuring the pipeline; a $TAG condition expresses it
directly.