Documentation: TaskSpawner GitHub Issues example doesn't explain how repository is determined

Problem

The "Auto-fix GitHub issues with TaskSpawner" example in the README shows:

apiVersion: axon.io/v1alpha1
kind: TaskSpawner
metadata:
  name: fix-bugs
spec:
  when:
    githubIssues:
      labels: [bug]
      state: open
  taskTemplate:
    workspaceRef:
      name: my-workspace

A new user reading this example would reasonably ask: "Which GitHub repository is this watching for issues?"

The answer is non-obvious: the repository is derived from the Workspace's repo URL. This critical connection is documented in the code comments (api/v1alpha1/taskspawner_types.go:39-41) but not in the README.

Why This is Confusing

1. The githubIssues section has no repo field
2. The connection to workspaceRef is not explained
3. Users might assume they need to configure the repository elsewhere
4. The Workspace is shown as a separate resource for cloning code, not for identifying the GitHub repo to poll

Current State

The actual behavior (from the code):

// GitHubIssues discovers issues from a GitHub repository.
// The repository owner and name are derived from the workspace's repo URL
// specified in taskTemplate.workspaceRef.
// If the workspace has a secretRef, it is used for GitHub API authentication.

This means:

• If workspace points to https://github.com/org/repo.git, TaskSpawner polls org/repo for issues
• The workspace's GitHub token (if present) is used for API auth
• The workspace serves dual purpose: code checkout AND GitHub API discovery

Impact

Users might:

• Not understand which repo is being watched
• Try to configure the repository in the wrong place
• Miss that the workspace token is used for both git clone and GitHub API access
• Be confused when the TaskSpawner only works for the repo in the workspace

Suggested Fix

Add a clear explanation in the TaskSpawner example:

### Auto-fix GitHub issues with TaskSpawner

Create a TaskSpawner to automatically turn GitHub issues into agent tasks.

**Important:** The GitHub repository to watch is determined by the Workspace's `repo` URL. For example, if `my-workspace` points to `https://github.com/your-org/your-repo.git`, the TaskSpawner will poll issues from `your-org/your-repo`.

```yaml
apiVersion: axon.io/v1alpha1
kind: TaskSpawner
metadata:
  name: fix-bugs
spec:
  when:
    githubIssues:         # Polls the repo from my-workspace
      labels: [bug]
      state: open
  taskTemplate:
    workspaceRef:
      name: my-workspace  # Must reference a Workspace with a GitHub repo URL

Or add it to the TaskSpawner reference section:

```markdown
| Field | Description | Required |
|-------|-------------|----------|
| `spec.when.githubIssues` | Discovers issues from the GitHub repository specified in `spec.taskTemplate.workspaceRef`'s Workspace repo URL | No |

Additional Context

Related to issue #170, but this is specifically about the conceptual model of how TaskSpawner determines which repo to watch, not just the prerequisite setup steps.

Start with the README's “Auto-fix GitHub issues with TaskSpawner” example and compare it with api/v1alpha1/taskspawner_types.go:39-41. Update the example or TaskSpawner reference to explain that the Workspace repo URL determines the GitHub repository and that its secret may provide authentication. Done means a new user can identify the watched repository from the example alone.