[plugins] Advise the cli-download role on a 403 from registry-packages-proxy

[Glitchy-Sheep]

Summary

The 403 diagnostic for d8 dist plugins told users to bind the wrong ClusterRole. They bound it and still got 403.

Problem

• Plugins are downloaded over /v1/images/
• kube-rbac-proxy authorizes that whole prefix through the deployments/cli-binary subresource
• That subresource is granted by d8:registry-packages-proxy:cli-download
• The diagnostic named d8:registry-packages-proxy:packages-download, which covers /v1/packages/ and is never called by the CLI
• So the advice led nowhere: bind the role, wait, get 403 again
• The same block also said "authorization is cached ~5 min - after binding, retry with a fresh token". A denial is cached for about 30 seconds, and the old token keeps working, so both halves were wrong
• The d8 dist copy of the diagnostic named the right role but carried the same wrong hint about the cache

Fix

• Advise cli-download for plugins
• Say that a denial is cached for about 30 seconds and the same token still works, in both copies of the diagnostic
• Add a short comment next to the case so the role is not "corrected" back later

Before / After

Before: a 403 on d8 dist plugins install <name> sent the user to packages-download, which does not open the route.

After: the same 403 sends the user to cli-download, the role that actually grants /v1/images/.

Tests

• TestDiagnose in internal/plugins/cmd/errdetect now pins cli-download in the 403 advice

Notes

• Source of truth: modules/039-registry-packages-proxy/templates/deployment.yaml in deckhouse maps /v1/images/ to subresource cli-binary and /v1/packages/ to packages
• Repo docs were already right (internal/plugins/README.md, internal/selfupdate/README.md); only the code lagged behind

[Glitchy-Sheep]

Moved into #451 - the fix rides along with the mirror push change instead of a separate PR.