Feature request: Named namespace-routing rewrite_tag filters

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

The auto-generated namespace-routing rewrite_tag filters created by `generateRewriteTagConfig` produce filter metrics with generic ordinal names like `rewrite_tag.0`. These names carry no information about which namespace a filter is routing, making it impossible (AFAICT) to correlate filter pipeline metrics (e.g. `fluentbit_filter_records_total`, `fluentbit_filter_drop_records_total`) back to a specific namespace. This is even worse when looking at metrics from multiple clusters, where the ordering can change (although the feature doesn't need to cover that case)

FluentBit supports the `Alias` property on all plugin types, and when set, it replaces the ordinal name in the `name` metric label. The operator already exposes `Alias` on CRD-defined filters (added in #370), and the emitters created by these rewrite_tag filters are already named via `EmitterName` but the filters themselves get no alias.

This makes it difficult to monitor per-namespace filter processing load, set up per-namespace alerts, or debug which rewrite_tag filter is causing issues in a busy pipeline.

### Describe the solution you'd like

Set `Alias` on the rewrite_tag filter struct in `generateRewriteTagConfig` (controllers/fluentbitconfig_controller.go), using a predictable name derived from the namespace. `namespace-routing-`? Naming is hard, I'll take anything you see fit.

After PR #2019 refactored this function to build a proper `filter.RewriteTag` struct, the change is minimal. `CommonParams.AddCommonParams()` already emits `Alias` when non-empty, so no renderer changes are needed.

This would make filter metrics show `name="namespace-routing-myapp"` instead of `name="rewrite_tag.5"`, consistent with how `EmitterName` already identifies the corresponding emitter input.

### Additional context

Related prior work:

- #356 / #370: Added Alias support to CRD-defined filters.
- #2019: Refactored `generateRewriteTagConfig` from manual string building to struct-based construction, which makes this change straightforward.
- fluent/fluent-bit#4694: Upstream FluentBit issue confirming Alias works as the metric name label.
- fluent/fluent-bit#6076: Open issue about duplicate alias collision in metrics (not a concern here since namespace names should be unique and therefore produce a unique alias).

Happy to submit a PR for this if the approach looks good.

Start in controllers/fluentbitconfig_controller.go at generateRewriteTagConfig and inspect the filter.RewriteTag construction. Check how CommonParams.AddCommonParams emits Alias and how EmitterName is assigned. Done means each generated namespace-routing filter has a predictable namespace-derived alias, with no renderer changes required.

Written by the indexing model from the issue text.