fix(ci): drop --remote from gh repo fork in OperatorHub submission (#58)

Modern `gh` CLI rejects `--remote` when a repository argument is also
passed, with:

  the --remote flag is unsupported when a repository argument is provided

This has silently failed the OperatorHub submission workflow on every
release since v0.10.2 (2026-03-31), so no bundle PR has been opened at
k8s-operatorhub/community-operators for any of v0.10.2..v0.11.0. The
listing on operatorhub.io is therefore stuck on whatever bundle was
last successfully submitted (the original v0.1.0).

`--remote` was redundant here anyway: `gh repo fork --clone` with a
repo argument creates the fork, clones it into the target directory,
and auto-configures `origin`=fork and `upstream`=canonical, which is
exactly what the subsequent `git fetch upstream main` needs.

After merge, re-trigger the submission for v0.11.0 with:

  gh workflow run "OperatorHub Submission" -f tag=v0.11.0

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: stubbi

.github/workflows/operatorhub.yaml

@@ -62,8 +62,11 @@ jobs:
           # Configure gh as git credential helper so git push works with the PAT
           gh auth setup-git
 
-          # Clone the community-operators repo (fork is auto-created by gh)
-          gh repo fork k8s-operatorhub/community-operators --clone=true --remote=true -- community-operators
+          # Clone the community-operators repo (fork is auto-created by gh).
+          # --remote is incompatible with passing a repo argument in modern gh;
+          # gh repo fork --clone already sets up origin=fork and upstream=canonical
+          # in the new clone.
+          gh repo fork k8s-operatorhub/community-operators --clone=true -- community-operators
           cd community-operators
 
           git config user.name "github-actions[bot]"