Track SaveMoney telemetry input sources

[mamu0]

This PR improves telemetry for the dx savemoney command so we can verify whether current observability is sufficient for SaveMoney usage analysis.

It adds OpenTelemetry attributes on the root span to capture:

• AZQR report source (cli, config, none)
• subscription source (config, env, prompt)
• output format, enabled sources, and pricing flag
• analyzed subscription count and findings/resource totals

Example result on Application Insight:

Resolves CES-2208

[kin0992]

question: are we sure we need this like this?

according to an RFC, we are going to remove the savemoney command from the CLI, so I would not invest on this (or at least I would do it differently)

[mamu0]

question: are we sure we need this like this?

@kin0992 Your point makes sense.
My thinking was that since this will be deleted entirely once separated, and the effort to implement it was minimal, a simpler change could suffice in the meantime.

according to an RFC, we are going to remove the savemoney command from the CLI, so I would not invest on this (or at least I would do it differently)

What alternative approach do you suggest?

[kin0992]

question: are we sure we need this like this?

@kin0992 Your point makes sense. My thinking was that since this will be deleted entirely once separated, and the effort to implement it was minimal, a simpler change could suffice in the meantime.

according to an RFC, we are going to remove the savemoney command from the CLI, so I would not invest on this (or at least I would do it differently)

What alternative approach do you suggest?

I would start thinking of savemoney as an independent and separate tool, callable through npx (e.g. npx @pagopa/savemoney <command>), so I would move in that direction. It's reasonable to have telemetry there (taking care of privacy concerns since potentially it is going to be used by anyone), so I would try to move in that direction.

Note that this is not a blocking comment: if you think that this way is best right now, then it's ok to me. It just seems to me that we are going to do the same work twice

[mamu0]

I would start thinking of savemoney as an independent and separate tool, callable through npx (e.g. npx @pagopa/savemoney <command>), so I would move in that direction. It's reasonable to have telemetry there (taking care of privacy concerns since potentially it is going to be used by anyone), so I would try to move in that direction.

@kin0992 Good point, I refactored this so telemetry mapping is now in @pagopa/dx-savemoney (not CLI-specific), and the DX CLI only forwards attributes to the active span (check this commit db570bf).

This keeps current telemetry working while minimizing rework for the future standalone savemoney entrypoint.

So we avoid doing the same work twice and keep the migration path cleaner.