[observability] ServiceMonitors, logging annotations and deploy metadata

[henzigo]

Context

• **** exporters (redis :9121, rabbitmq :15692) have no scrape wiring — Prometheus needs
  static config; the Services already carry the prometheus-exporter: 'true' label
• **** storefront pods have logging/enabled: "false" — if the log collector honors the
  annotation, storefront logs are dropped entirely
• **** no way to tell from the cluster who deployed what — no commit SHA / pipeline
  annotations
• (cron FIFO logging is addressed by [app] Align cron lifecycle with deployment#72 (Recreate, foreground crond, console lock/watch) #25/[security] Run the cron container without root (supercronic) #3/[proposal] Evaluate native Kubernetes CronJobs instead of the crond Deployment (investigation) #19)

Proposal

1. Optional ServiceMonitor templates (values-gated monitoring.serviceMonitors.enabled,
   Prometheus Operator prerequisite documented) for redis + rabbitmq exporters; fallback
   prometheus.io/scrape annotations as a second values-gated option for annotation-based
   setups.
2. Make the logging/enabled annotation a per-component value and revisit the storefront
   default ("false" inherited from legacy — decide consciously).
3. Deployment metadata annotations rendered from values the wrapper passes through
   (shopsys.com/commit-sha, shopsys.com/pipeline-url, shopsys.com/deployed-at) — pod
   annotations must NOT include per-deploy values that would force needless rollouts; put them
   on the resource metadata only.

Tasks

• ServiceMonitor templates + values + docs (kubeconform needs the CRD schema or skip)
• logging/enabled as component value + storefront default decision
• Deploy metadata annotations + wrapper passthrough
• Unit tests, golden snapshots

Related: #24 (TTFB probes)