Provision robot accounts from values and publish their secrets to Kubernetes Secrets

Problem

Non-interactive consumers of the registry (CI, an in-cluster indexer such as the Collab Hub cog catalog) need a credential that is not a human's CLI secret. Harbor's answer is a robot account, but:

• Harbor returns the robot's secret exactly once, in the create response. If nobody captures it into a Secret at creation time, it is gone.
• The instance default robot_token_duration is 30 days. A robot created without an explicit duration expires silently and the consumer starts getting 401s a month later.
• Today robots are created by hand in the UI, so they do not survive a fresh install.

Proposal

Add bootstrap.robots[] and provision them from the same post-install job as #2, writing each robot's name and secret into a Kubernetes Secret:

bootstrap:
  robots:
    - name: hub-cog-indexer
      level: project            # project | system
      project: cogs
      duration: -1              # days; -1 = never expires (default). Never rely on the instance default.
      # default permission set = pull-only:
      #   repository:pull, artifact:read, artifact:list, tag:list
      permissions: []           # override with explicit {resource, action} pairs if needed
      secret:
        name: harbor-robot-hub-cog-indexer
        namespace: ""           # defaults to the release namespace

API surface: POST /api/v2.0/robots (v2 robot with level, duration, permissions[].{kind, namespace, access[]}), GET /robots?q=name=... for lookup, PATCH /robots/{id} to refresh the secret.

Secret contents: username (Harbor prefixes it, e.g. robot$cogs+hub-cog-indexer; store the full username Harbor returns), password, and registry (the harbor.externalURL host) so a consumer can build a docker-style auth entry without extra lookups.

Requirements

• Idempotent: if the Secret exists and the robot exists, do nothing. If the robot exists but the Secret is missing (e.g. Secret deleted, or robot created before this feature), refresh the robot secret and write it. Never overwrite an existing Secret with a new secret unless the robot was rotated.
• Writing a Secret into another namespace needs a Role/RoleBinding for the job's ServiceAccount in that namespace; render it only when secret.namespace is set and differs from the release namespace. Document the cross-namespace trade-off (the consuming chart may prefer to reflect the Secret itself).
• The job must not log the secret.
• Depends on #2 (project must exist before a project-level robot can be created).

Acceptance

• Fresh make up-sso with a robot entry produces a robot in Harbor and a Secret with a working pull credential (curl -u against /service/token with the repository:pull scope returns a token).
• helm upgrade re-run is a no-op; deleting the Secret and re-running restores it with a freshly rotated secret.
• The robot's expiry in the Harbor UI shows "never" (or the configured duration), not the instance default.
• README values reference + docs page for consumers ("Registry Setup" already has a robot-account paragraph that can link here).

Context

Motivated by nebari-dev/collab-hub-pack#7 (hub indexer needs a pull-only robot on the cogs project). Related: #2 (projects), #4 (webhook provisioning), #6 (in-cluster consumer docs).

Start with the post-install job from #2 and the Helm values used by the pack. Review Harbor's POST /api/v2.0/robots, GET /robots, and PATCH /robots/{id} flows, then trace Secret and cross-namespace Role/RoleBinding rendering. Done means the listed acceptance checks pass, including idempotent upgrades, rotation after deletion, expiry configuration, and README plus Registry Setup documentation.