Refactor how we get the private key secret ID

### Enhancement Proposal

We currently use a private method (`_get_private_key_secret_label()`) from the `tls-certificates` library to access the label of the private key secret, then use that label to retrieve the secret, grant the workers access to it, and pass its ID to related worker units so that they can later retrieve the private key.

This tightly couples us to an internal implementation detail of the library. If the lib changes how secrets are labelled or stored, our charm could silently break.

We should either:
1- Use the library’s public API to retrieve the private key, then create our own secret using a label we manage.
2- Ask the TLS team if they’re willing to expose the label-generating method or perhaps the secret itself (e.g, the secret ID ) as part of the public API. (https://github.com/canonical/tls-certificates-interface/issues/354)

Start by tracing uses of _get_private_key_secret_label() and review tls-certificates-interface issue #354. Decide whether the charm should use the library’s public API and manage its own secret label, or use an exposed label or secret ID. Done means the charm no longer depends on that private method while workers can still receive the private-key secret ID.

Written by the indexing model from the issue text.