guaccollect accepts --enable-prometheus on every subcommand but only deps-dev honours it

[gaganhr94]

--enable-prometheus is registered as a persistent flag on the guaccollect
root command (cmd/guaccollect/cmd/root.go:40), so every subcommand accepts it.
Only one subcommand reads it.

Code (at 1e98dab2): the sole consumer is
cmd/guaccollect/cmd/deps_dev.go:92 (viper.GetBool("enable-prometheus")).
The other twelve subcommands — blob, datadog_malware, eol, files, gcs,
github, kubescape, license, oci, osv, s3, scorecard — never read
the value.

Impact: guaccollect osv --enable-prometheus (and the same for any
subcommand but deps-dev) is accepted, exits 0, starts no metrics server, and
reports nothing. The user has no signal that the flag did nothing. Same applies
to GUAC_ENABLE_PROMETHEUS, since the root binds viper with the GUAC prefix.

Related inconsistency: --prometheus-port is not a root persistent flag —
it is registered locally on deps-dev only
(cmd/guaccollect/cmd/deps_dev.go:211). So on every other subcommand you can
ask for Prometheus but cannot set its port, which is a good indication the
persistent registration of --enable-prometheus was not intended to be
binary-wide.

Possible fixes, in rough order of preference:

1. Wire the metrics server up in the shared collector path so the flag works
   everywhere it is accepted (and promote --prometheus-port to match).
2. Move both flags off the root and register them locally on deps-dev, so the
   other subcommands reject them with unknown flag.
3. At minimum, log a warning when the flag is set on a subcommand that ignores
   it.

Option 1 is the one that matches user expectation — the flag is currently
documented in guac-docs as a general guaccollect flag.