Enhancement: Python client cannot read a parameter's bound expression (`in power = powerPort.power;`); only constant values are exposed

Start with the attached repro.py and model to reproduce the missing binding in the Python client, then trace how Symbol facts and attribute_facts() expose parameter values. The requested API should report the binding expression, default status, and referenced features for feature chains while retaining folded constants. Also investigate why reflection returns an empty targetFeature.qualifiedName; done means the reproduced bindings and target feature are accessible through the relevant APIs.

This issue was written with AI help. The model, the reproduction script and its output are
attached and were run against the version below.

This is mainly a feature request. The issue form points feature requests to Discussions, but
Discussions are not enabled on this repository, so it is filed as an issue.

What happened, and what you expected instead

An action performed by a part binds its input parameter to a feature of the part's port:

part def Motor {
    port powerPort : PowerPort;
    perform action consume : Consume {
        in power = powerPort.power;          // bound to a feature chain
        in gain = 0.5;                       // literal
    }
    action boost : Consume {
        in power = powerPort.power * 2.0;    // operator expression
    }
}

A client walking the model (to generate an interface table, a simulation wiring, or code) needs
to know what each parameter is bound to. From Python:

Route	consume::power = powerPort.power	consume::gain = 0.5	boost::power = powerPort.power * 2.0
parameter Symbol (metadata, type_facts)	direction in, type Real; no value	same	same
owner's attribute_facts() value	None	0.5 ✔	None
model.query	no property carries a value	same	same
reflection, ….metadata.ownedRelationship (the FeatureValue)	UnsupportedValueError: metaobject of an element with no qualified name	same	same
api-json	FeatureValue → FeatureChainExpression, targetFeature = PowerPort::power ✔	FeatureValue → LiteralRational 0.5 ✔	FeatureValue → OperatorExpression '*' ✔

So a value is exposed only when it folds to a model-level constant (AttributeFacts.value is
documented that way: "Default value, when it is a model-level constant"). An expression that
refers to another feature, which is the normal way to wire a parameter, is invisible: there is
no text, no referenced feature, and no indication that the parameter is bound at all. The only
route to it is exporting the whole model as api-json and following
ownedRelationship → FeatureValue.value → the expression tree.

Requested: the Symbol API reports a feature's value binding when there is one. At minimum
that means the expression's source text and whether it is a default (isDefault/isInitial).
For a feature-chain expression it should also give the referenced features
(powerPort → PowerPort::power), so a client can follow the binding without parsing text.
AttributeFacts.value could stay as the folded constant beside it.

One reflection defect found on the way: even when navigating straight through the anonymous
elements, last(…::consume::power.metadata).ownedRelationship.value.targetFeature.qualifiedName
returns []. KerML v1.1 §8.3.4.8.4 derives FeatureChainExpression::targetFeature, and
api-json writes it as PowerPort::power. The anonymous-element limitation of reflection
(UnsupportedValueError) is the same one described in #1957.

Reproduction

$ python repro.py          # loads model.sysml with opensysml.loads() over sysml-grpc
## consume::power = powerPort.power
[OK  ] consume::power: Symbol reports direction and type
       observed: {'metadata': {'visibility': 'default', 'direction': 'in'}, 'type_facts.primitive': 'Real'}
[INFO] consume::power: owner's attribute_facts() value
       observed: None
[BUG ] consume::power: the Symbol API exposes the value or expression
       observed: {'facts': {'metadata': {'visibility': 'default', 'direction': 'in'}, 'type_facts.primitive': 'Real'}, 'value': None}
       expected: 'the expression `powerPort.power` (text, and for a chain the referenced feature)'
[INFO] consume::power: reflection ownedRelationship (the FeatureValue)
       observed: UnsupportedValueError('unsupported: metaobject of an element with no qualified name')
[OK  ] consume::power: api-json has FeatureValue -> FeatureChainExpression
       observed: {'@type': 'FeatureChainExpression', 'targetFeature': {'@id': 'ParameterValues__PowerPort__power'}}

## consume::gain = 0.5
[INFO] consume::gain: owner's attribute_facts() value
       observed: 0.5

## Reflection: FeatureChainExpression::targetFeature of consume::power
[BUG ] consume::power: ownedRelationship.value.targetFeature is PowerPort::power
       observed: []
       expected: ['ParameterValues::PowerPort::power']

model.sysml:
package ParameterValues {
    port def PowerPort {
        out attribute power : ScalarValues::Real;
    }

    action def Consume {
        in power : ScalarValues::Real;
        in gain : ScalarValues::Real;
    }

    part def Motor {
        port powerPort : PowerPort;

        perform action consume : Consume {
            in power = powerPort.power;          // bound to a feature chain   -> not exposed
            in gain = 0.5;                       // literal (for comparison)   -> exposed as a value
        }

        action boost : Consume {
            in power = powerPort.power * 2.0;    // operator expression        -> not exposed
        }
    }
}

Reproduction files (attached)

File	Contents
model.sysml.txt	the model above (GitHub does not accept .sysml uploads): rename it to model.sysml next to repro.py
repro.py	loads model.sysml with opensysml.loads() and, for each parameter, checks the Symbol facts, the owner's attribute_facts(), the query API, reflection and the api-json export. Each check prints OK, BUG or INFO, and the script exits 1 while any BUG reproduces.
_common.py	shared helper the script imports: starts the sysml-grpc named by $OPENSYSML_BINARY, prints the server and client versions, and formats the checks
output.txt	the full output of the run reported here

model.sysml.txt

repro.py

_common.py

output.txt

To run it, put _common.py in the parent directory of the folder holding repro.py and the model,
install the client (pip install -e client/python from an OpenSysML checkout), and point
OPENSYSML_BINARY at a sysml-grpc build:

$ OPENSYSML_BINARY=/path/to/OpenSysML/bin/sysml-grpc python repro.py

Without OPENSYSML_BINARY, _common.py assumes an OpenSysML checkout next to the directory
that holds _common.py, with bin/sysml-grpc built by make build-grpc.

Version

sysml-grpc v0.12.0-262-gc86932321 (develop at c86932321), opensysml Python client 0.12.0, Python 3.13.15

Surface

Python client (opensysml)