Replace dev/pub/pkg abbreviations with clear product names at user-facing boundaries

Summary

The operator uses abbreviated product names — dev (Workbench), pub (Connect), pkg (Package Manager) — in user-facing secret key names, documentation, and examples. These abbreviations are confusing for non-engineers and anyone not deeply familiar with the project's internal naming conventions.

Problem

An integrator setting up team-operator must create secrets with keys like:

• dev-db-password, dev-license, dev-client-secret (Workbench)
• pub-db-password, pub-license, pub-client-secret, pub-smtp-host (Connect)
• pkg-db-password, pkg-license, pkg-secret-key (Package Manager)

Nothing about dev, pub, or pkg intuitively maps to Workbench, Connect, or Package Manager. This creates unnecessary friction and a source of misconfiguration.

Where these appear

• Secret key names — the primary user-facing impact. Users must follow these conventions when creating Kubernetes secrets or AWS Secrets Manager entries.
• Documentation — guides for authentication, Connect config, Workbench config, Package Manager config, and troubleshooting all reference these abbreviated keys.
• Example YAMLs — config/samples/test-secret.yaml
• Architecture docs — database user names (pub-user, dev-user, pkg-user)

Note: CRD field names, Helm values, and Go API struct names do not use these abbreviations.

Proposed Change

Replace abbreviated secret key prefixes with clear product names:

This will be a breaking change to secret key conventions, so it should include a migration path (e.g., support both old and new keys during a transition period).

Begin with config/samples/test-secret.yaml and search the authentication, Connect, Workbench, Package Manager, troubleshooting, and architecture documentation for the listed keys. Establish the old/new compatibility and migration behavior first; done means every user-facing key and example follows the chosen product names without changing CRD fields, Helm values, or Go API struct names.