feat: Implement named-object commands using root-level commands

[mkundu1]

Context

The common commands at named-objects (like create, rename etc.) will be moved under settings root in settings API. In the first phase, only list and list_properties have been moved in settings API. Those commands will still appear at named-objects from Python code, we have to change their implementation in PyFluent to route them via the root-level commands.

Change Summary

Implemented named-object commands list and list_properties using the root-level commands.

Rationale

The rationale is in the settings API side which is to reduce the size of static-info. The PyFluent side changes are to adapt to that rationale.

Impact

There will be no change in the Python API usage.

[Copilot]

Pull Request Overview

This PR implements named-object commands (list and list_properties) using root-level commands to adapt to changes in the settings API that move these commands from named-objects to the settings root. This change reduces static-info size while maintaining backward compatibility.

• Added list() and list_properties() methods to the NamedObject class that route to root-level commands
• Implemented parameter name handling to resolve conflicts between method parameters and existing properties
• Added comprehensive test coverage for both instance methods and static class methods

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
src/ansys/fluent/core/solver/flobject.py	Added list and list_properties methods to NamedObject class and parameter handling for path conflicts
src/ansys/fluent/core/services/settings.py	Updated execute_cmd method to handle parameter renaming from path_1 back to path
tests/test_settings_api.py	Added test function to verify named-object commands work correctly
doc/changelog.d/4398.added.md	Added changelog entry documenting the new feature

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[seanpearsonuk]

@gyeole @h-krishnan @mkundu1

Considering the change holistically from the server API onward, could this introduce more complexity for external developers constructing clients, particularly those handling settings APIs generically across products like Fluent, CFX, etc.?

I’m wondering whether moving these commands to the root level makes sense in the broader context of the settings API as a potential cross-product blueprint.

From a trade-off perspective, is the reduction in static info size the primary motivation, or do we expect additional tangible benefits that offset the added indirection?