`hierarchical_topics()` parent nodes show raw c-TF-IDF keywords instead of representation model labels

Nobody has claimed this yet.

### Feature request

`hierarchical_topics()` builds parent topic names by concatenating the top 5 c-TF-IDF keywords — e.g., `"wear_safety_PPE_worker_work"`. Meanwhile, leaf topics get rich labels from the representation model (e.g., `"PPE Non-Compliance Incidents"` via an LLM). This creates a jarring inconsistency in `visualize_hierarchy()`.

Add a `use_representation_model` parameter that runs the representation pipeline on parent topics:

```python
# Current: parent nodes show "wear_safety_PPE_worker_work"
hierarchy = topic_model.hierarchical_topics(docs)

# Proposed: parent nodes get proper labels from the representation model
hierarchy = topic_model.hierarchical_topics(docs, use_representation_model=True)
```

### Motivation

**Root cause:** `_extract_words_per_topic` is called with `calculate_aspects=False` for parent nodes, so no aspect models (including LLM labeling) run on them.

When using LLM-based representation models, the hierarchy visualization becomes unusable because leaf labels (e.g., `"PPE Non-Compliance Incidents"`) are at a completely different abstraction level than parent labels (e.g., `"wear_safety_PPE_worker_work"`). Users must manually relabel parent nodes, which defeats the purpose of the representation pipeline.

### Your contribution

I can submit a PR that adds `use_representation_model: bool = False` to `hierarchical_topics()`. When enabled, a post-processing step runs the full representation pipeline on all parent topics in a **single batch call** — not inline during the merge loop (which would make N-1 separate LLM calls).

Default is `False` — existing behavior unchanged. The batch approach keeps LLM cost bounded.

**Note:** If the shared helpers refactoring (#2497) lands first, this PR can reuse `_aggregate_documents()`. Otherwise, the aggregation is inlined — either way works.

I've already been prototyping this in my fork, so I can open a PR quickly if the approach looks good to you.

---

Start with hierarchical_topics() and trace its _extract_words_per_topic(..., calculate_aspects=False) path for parent nodes. Review the proposed interaction with the representation pipeline and the shared helpers refactoring in #2497, while ensuring parent processing is batched rather than performed in the merge loop. Done means an opt-in use_representation_model parameter produces representation-model labels for parent nodes while preserving the default behavior.

Written by the indexing model from the issue text.