The pull request is the subject, not the input

[czpython]

Starting a review wrote the same facts twice:

return await cls.start(
    subject=Subject(id=f"{repo}#{pr_number}", subject_type=Review.subject_type),
    account_id=account.id if account else None,
    repo=repo,
    pr_number=pr_number,
    requested_by=requested_by,
)

repo and pr_number were both the subject and the run input. Now that PullRequest is a subject class that knows its own repo and number, the input goes — there is no new SDK surface, no derived-subject mode, no way to omit subject=.

class PullRequestReview(Workflow):
    subject = PullRequest

    @classmethod
    async def dispatch(cls, *, repo: str, pr_number: int, requested_by: str) -> str:
        account = Account.get_for_username(requested_by)
        return await cls.start(
            subject=PullRequest.get_for(repo, pr_number),
            account_id=account.id if account else None,
            requested_by=requested_by,
        )

    async def run(self, requested_by: str) -> None:
        ...

get_workspace_kwargs(), get_prompt_context() and the reviewer's prompt read self.subject.repo and self.subject.number. The body keeps requested_by — that one is the request's own, not the pull request's.

The launch contract is unchanged: every domain run passes subject=, background work passes subject=None, and losing a timeline by accident still fails loudly.

A review already queued carries the old pair in its durable payload. Extra keys are ignored on re-validation and the subject rides separately, so it replays through the declaration — pinned by a test that binds an old payload.

The argument against: future row-less workflows repeat a small dispatcher pattern. A generic hook is worse — get_subject(**input) would receive every body field including requested_by, there is no bound workflow instance before enqueue, and it needs signature reflection for one consumer.