refactor: Bind catalog DataName values with nameof

[DaveSkender]

Fixes #2194

Problem

Catalog DataName values were string literals that had to match a property on the indicator's result record. Nothing tied them together, so a renamed or removed property left the catalog advertising a field that could never be populated — the defect class behind PRS.Sma and VWAP.UpperBand (#2187). Catalog.Binding.Tests (#2189) made that drift detectable at test time; this makes it impossible at compile time.

Change

All 214 AddResult sites across 85 catalog files convert from string literals to nameof(TResult.Property):

.AddResult(nameof(EmaResult.Ema), "EMA", ResultType.Default, isReusable: true)

Each TResult was derived from the listing's own runtime ResultRecordType — not filename convention — so the type named is the one the bound method actually returns (BARPART → TimeValue, candle patterns → CandleResult, WILLR → WilliamsResult, and so on). displayName stays a literal; it is a human label, not a member name. The indicator-catalog skill, the builder's XML doc, and the catalog README now teach the nameof form (the README example also named a builder class that does not exist — fixed).

Zero wire effect — verified byte-for-byte

Every DataName already matched its property name exactly (ordinal), so nameof produces the identical string at all 214 sites. Catalog.Get().ToJson() is byte-identical before and after — same 288,354 bytes, same SHA-256 (2ca9aef4…) — re-verified against current main (54118590) after rebase. Nothing here belongs to a breaking wave; this is a refactor with no observable output change.

Proof the guarantee moved, with a control

Renaming EmaResult.Ema → EmaValue:

	errors from Ema.Catalog.cs
after this change	CS0117: 'EmaResult' does not contain a definition for 'Ema' — net10.0, net9.0, net8.0
before (main)	0 — the stale literal compiled fine

What the runtime test still covers

Catalog.Binding.Tests is not redundant afterward: nameof cannot reach a method's parameter list, so ParameterName keeps its runtime check — the more damaging half, since a stale parameter name silently substitutes a default. The test also catches a listing bound to a real method of the wrong style, and non-contiguous parameter order.

The one site nameof cannot reach — CatalogListingBuilder.AddPriceHlcResult, which hardcodes "High"/"Low"/"Close" with no result type in scope — has no catalog callers (verified; only a builder unit test uses it) and is left as-is.

Review provenance

Self-review lane independently rebuilt the verification with its own reflection harness: all 214 sites parsed and compared against each listing's runtime ResultRecordType — zero wrong-but-compiling types; multiset equality of removed/added strings confirmed byte-identity by construction. Verdict 0 critical, 1 non-critical (the README example, fixed above).

Build:       0 Warning(s), 0 Error(s)   (--no-incremental; incl. Roslynator.Analyzers 5.0.0 post-rebase)
Unit:        Failed: 0, Passed: 2523, Skipped: 12
PublicApi:   Failed: 0, Passed: 76
Integration: Failed: 0, Passed: 4, Skipped: 1
markdownlint-cli2: 0 issues in 183 files
dotnet format --severity info: clean

Diff shape: 85 catalog files at exactly one changed token per AddResult line (214 insertions / 214 deletions), plus three doc files.

[facioquoqa]

FaciōQuōqa Mage Reviewer is standing by.

• Trigger review

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 0 complexity · -7 duplication

Metric	Results
Complexity	0
Duplication	-7

View in Codacy

🟢 Coverage 100.00% diff coverage · +0.00% coverage variation

Metric	Results
Coverage variation	✅ +0.00% coverage variation (-1.00%)
Diff coverage	✅ 100.00% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (e8f4adb)	19600	18914	96.50%
Head commit (3089505)	19600 (+0)	18914 (+0)	96.50% (+0.00%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#2204)	214	214	100.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}