[MISC] Stop tracking channel for held snaps

[dragomirp]

Remove tracking of snap channel for the charmed-postgresql snap

[codecov[bot]]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 74.50%. Comparing base (d973b19) to head (6884459). Report is 1 commits behind head on main.

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #384 +/- ## ======================================= Coverage 74.50% 74.50% ======================================= Files 9 9 Lines 1322 1322 Branches 228 228 ======================================= Hits 985 985 Misses 262 262 Partials 75 75 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[lucasgameiroborges]

Huh, just realized this is going to break the automation for pinning snap revs in bundles :(

Question: Will the channel be specified anywhere else in the charm code? Will there be any other "source of truth" for the channel of the snap? Wondering if I can avoid hard-coding it in the workflow.

[dragomirp]

Question: Will the channel be specified anywhere else in the charm code? Will there be any other "source of truth" for the channel of the snap? Wondering if I can avoid hard-coding it in the workflow.

Technically the channel stated is wrong, there's no revisions in it ATM. We can set the correct risk (14/edge and 1/edge), but then we can't change it when releasing a charm revision to stable. Is the revision itself not enough for store pinning to work?

[taurus-forever]

Huh, just realized this is going to break the automation for pinning snap revs in bundles :(

Follow MySQL approach for now: https://github.com/canonical/data-platform-workflows/blob/main/python/cli/data_platform_workflows_cli/update_bundle.py#L121