fix(metrics): update FSC to adopt provider-side collector caching

[EvanYan1024]

Motivation

Metric collectors are requested per finality listener and per TMS, and the FSC prometheus provider used to swallow duplicate registrations (SkipRegisterErr: true): later requesters silently received an unregistered collector, so their observations never showed up on /metrics, and every request paid a registry round-trip under the registry lock. We hit both in our test environments under sustained load.

Per the review discussion here, the deduplication was moved down into the smart client: hyperledger-labs/fabric-smart-client#1582 (merged) caches collectors inside the prometheus provider, so every consumer is protected. This PR adopts it and removes the token-sdk-side workaround.

Changes

• Bump fabric-smart-client to v0.14.3-0.20260716084917-c10decb043ec (the fix(metrics): cache collectors in the prometheus provider hyperledger-labs/fabric-smart-client#1582 merge commit) across all modules, with the transitive updates that come with it (fabric-lib-go, fabric-x-common, grpc). Happy to swap this to the next FSC tag once it is cut.
• Drop the recoverFromDuplicate workaround in tmsProvider: the provider no longer panics on duplicate registration, so the recover path is dead code — and it had a latent bug (recovering swallowed the panic and returned a nil collector to the caller).
• Adapt to the operations.NewMetricsProvider signature change (the skipRegisterErr parameter was removed in fix(metrics): cache collectors in the prometheus provider hyperledger-labs/fabric-smart-client#1582).

Tests

• token/core/common/metrics keeps the TMS label-decoration tests; the recover-path tests are removed with the workaround.
• Full go test -race ./token/... passes against the bumped FSC.
• The caching behavior itself is covered by the FSC provider tests added in fix(metrics): cache collectors in the prometheus provider hyperledger-labs/fabric-smart-client#1582.

Fixes #1906

[adecaro]

Hi @EvanYan1024 , thanks for submitting this.

What about a more radical solution that modifies the metrics.Provider implementation to cache the metrics and return the ones that exist already? I fear that we might have similar issues elsewhere.

What do you think?

[EvanYan1024]

Agreed, this direction is better — pushing the deduplication down into the provider as a single choke point fixes the whole class of issues in one go, not just these finality collectors.

[adecaro]

I think @mbrandenburger can be interested in this one. If we inject the caching mechanism directly in the smart client, we are protected also there.

[EvanYan1024]

@adecaro Moved the fix into the smart client's provider as suggested: hyperledger-labs/fabric-smart-client#1582 (issue hyperledger-labs/fabric-smart-client#1581). The provider now caches collectors by fully-qualified name, so repeated requests share the collector registered first and skip the registry entirely. Once that lands, this PR can be closed or reduced to a dependency bump.

[adecaro]

Hi @EvanYan1024 , so hyperledger-labs/fabric-smart-client#1582 has been merged. As soon as FSC cuts a new tag, we can update also panurus and we should be good. What do you think?

[EvanYan1024]

Sounds good @adecaro! Once FSC cuts the tag I'll update this PR: drop the decorator caching, bump FSC, and adapt the operations.NewMetricsProvider call in integration/nwo/runner/rpc/executor.go (the skipRegisterErr parameter was removed in FSC #1582). While at it, recoverFromDuplicate in the TMS provider becomes dead code and can be removed too.

[EvanYan1024]

@adecaro I've gone ahead and reworked this PR: it now bumps FSC to the hyperledger-labs/fabric-smart-client#1582 merge commit (v0.14.3-0.20260716084917-c10decb043ec), drops the decorator and the recoverFromDuplicate workaround, and adapts to the NewMetricsProvider signature change. Once the new FSC tag is cut I'll swap the pseudo-version to it — or feel free to merge as-is if the pseudo-version works for you.

[adecaro]

Thanks @EvanYan1024. We have a much robust solution now. Great effort 🙏

[adecaro]

LGTM