High-level documentation gap: Journaling vs first-class PyFluent Python APIs

## Summary

The PyFluent documentation needs a **prominent, high-level section** that clearly explains the distinction between **journal-generated Python** and **first-class PyFluent Python APIs**.

At present, the User Guide includes a journaling page that explains how PyFluent scripts can be generated from Fluent under certain constraints (e.g. meshing workflow GUI actions are journaled, solver GUI actions are not, etc.). However, the documentation does **not** make clear that:

* Journal output is **not** first-class PyFluent code
* Many PyFluent-specific abstractions and best practices are **never** represented in journal output
* Journaled code reflects only commands issued to Fluent, not effective Python usage

This leads users to incorrectly treat journal output as the canonical or recommended way to write PyFluent scripts.

## Problem Statement

### What the docs currently imply

By focusing on how to generate PyFluent scripts via journaling—without strong caveats—the documentation implicitly suggests that:

* Journaled Python is a good starting point for PyFluent development
* Journals represent idiomatic or recommended PyFluent usage

### What is actually true

1. **Journal output is not first-class PyFluent script**
Journaled code is a mechanical record of commands sent to Fluent. It is not designed to:

* Be idiomatic Python
* Reflect PyFluent abstractions
* Demonstrate good structure, reuse, or composition

2. **Journal output is inherently limited**
It contains only:

* Commands issued to Fluent

It does *not* include:

* Program logic (control flow, functions, composition)
* Queries or inspection of solver state
* Error handling or validation
* Integration with the wider Python ecosystem (NumPy, pandas, plotting, automation, etc.)

3. **Key PyFluent abstractions are never journaled**
Many PyFluent-specific APIs and higher-level constructs simply do not appear in journal output, so users relying on journals will never discover them.

## Why This Matters

### Cultural and behavioural impact

* **Legacy users are strongly conditioned to rely on journals** and often treat them as the "ground truth" for automation.
* **If some internal Ansys staff were to reinforce this mindset**, it would spread the idea that journaling is the correct or preferred approach.
* This may result in users producing brittle, verbose, and inefficient scripts while missing the real value of PyFluent.

### User profile reality

* Many PyFluent users are *not* professional software developers.
* Programming is a tool, not their primary discipline.
* Without clear guidance, these users naturally gravitate to journaling because it feels familiar and safe.

This makes it essential that the documentation actively **educates users**, rather than passively allowing legacy workflows to dominate.

## Proposed Documentation Changes

1. **Add a prominent, high-level documentation section** (not a buried subsection) titled along the lines of:

* "Journaling vs First-Class PyFluent Python APIs"

2. Clearly state that:

* Journal-generated Python is **not** first-class PyFluent code
* Journals should be treated as a *recording/debugging aid*, not a development model

3. Explicitly position the recommended learning path as:

* Python fundamentals
* PyFluent online documentation
* Curated PyFluent examples

4. Explain why journaled code:

* Is not idiomatic
* Is not efficiently structured
* Does not represent the full PyFluent API surface

5. Encourage a mindset shift:

* PyFluent as a Python API first
* Journaling as a secondary, limited tool

## Acceptance Criteria

* A new, clearly visible documentation section explaining journaling vs first-class PyFluent usage
* Explicit statements that journal output is not idiomatic or recommended PyFluent code
* Clear guidance on how users should learn and write PyFluent scripts effectively
* Documentation language that actively discourages over-reliance on journaling

## Outcome

This change aims to:

* Set correct expectations for new users
* Help legacy users transition away from journal-centric workflows
* Improve overall script quality and API adoption
* Drive a cultural shift toward treating PyFluent as a modern Python-first interface

Start with the existing User Guide journaling page and inspect the surrounding documentation structure for an appropriate prominent location. Add a section contrasting journal-generated Python with first-class PyFluent APIs, including the recommended learning path and journaling limitations; done means the acceptance criteria are stated clearly for new users.

Written by the indexing model from the issue text.