“Headless” mode

An optional mode whereby this plugin acts not as a branch source but simply a webhook receiver, performing the bare minimum number of API requests to run a build. This would be aligned with the stated purpose of Origin: to handle a huge number of PRs and even throwaway repos created by agents, which presumably do not care about nice display in the Jenkins controller. (#9 should suffice for most feedback purposes, with MCP available on a build URL in case more detail is needed.)

The hook body should already specify an owner, repo, and commit hash, which is enough to start the build, though it should optionally allow use of `Jenkinsfile` (rather than a fixed `CpsFlowDefinition`) to run the build, which will require an API call to load `Jenkinsfile` contents; plus any `checkout scm` (which should check out that exact commit, the same as `Jenkinsfile`), both of which will require one installation token (but #20 should amortize that).

Precise UX TBD, but I think it would suffice to have a single `WorkflowJob` with an associated app covering an entire owner. Any repo on which the app is installed would send webhooks to it, so its build history would be a meaningless jumble, and old builds could be deleted quickly (kept just long enough for any agentic triage). Plugin features sensitive to history (`junit` regression/fixed markers, `warnings-ng` trends, `parallel-test-executor` historical data, etc.) would not work: every build would exist in isolation.

Start by reading the requirements around webhook owner, repository, and commit data, then review the references to #9 and #20. Map how a single WorkflowJob, optional Jenkinsfile loading, CpsFlowDefinition, and checkout scm would fit together. No files or tests are named, and done is not defined until the precise UX and history behavior are decided.

Written by the indexing model from the issue text.