plan post-update verification skips assignee, leaving develop to reject #106

Summary

PLAN_AGENT_PROMPT's Post-Update Verification block (askcc/definitions.py:170-173) re-reads the issue body and confirms ## Acceptance Criteria (with - [ ]) + ## Dependencies headings — but does not verify the assignee. The plan prompt instructs the agent to run gh issue edit <url> --add-assignee "@me" (definitions.py:164); if the agent skips that step, the verification loop does not catch it, and develop's validate_issue_readiness (functions.py:362-371) rejects the issue.

This is the same class of contract gap as #96, just for the assignee check rather than the AC/Dependencies headings.

Reproduction

askcc plan runs against an unassigned issue and reports success. gh issue view <url> --json assignees returns []. askcc develop then fails pre-flight with [FAIL] Assignee confirmed: No assignee even though the body otherwise satisfies the readiness checks.

Why this slipped through #96's fix

#96 (PR #98) tightened the AC/Dependencies wording and added a verification loop, but that loop was scoped to the two body headings. The assignee step at definitions.py:164 is a one-shot instruction with no verification follow-up, so a missed gh issue edit --add-assignee produces a silent failure mode identical to the original #96 symptom.

Validator scope (for reference)

validate_issue_readiness at askcc/functions.py:322-387 runs four checks:

1. _has_acceptance_criteria(body) — covered by current verification loop.
2. _has_dependencies_section(body) — covered.
3. assignees non-empty — NOT covered.
4. No blocking labels — author-controlled, not plan's responsibility.

Proposed fix

Extend the Post-Update Verification block to fetch assignees alongside body and require at least one assignee, with the re-edit/re-verify loop wrapping all three checks:

```diff
-Re-read the body (`gh issue view --json body -q .body`) and confirm both
-`## Acceptance Criteria` (with a `- [ ]` checklist item) and `## Dependencies` (or
-Prerequisites/Context/Blockers) headings are present. Re-edit and re-verify until both pass —
-`develop` rejects the issue otherwise.
+Re-read the body and assignees (`gh issue view --json body,assignees`) and confirm
+(a) `## Acceptance Criteria` heading with a `- [ ]` checklist item, (b) `## Dependencies`
+(or Prerequisites/Context/Blockers) heading is present, and (c) at least one assignee is set.
+Re-edit / re-assign and re-verify until all three pass — `develop` rejects the issue otherwise.
```

This mirrors the three plan-controllable checks in validate_issue_readiness and closes the contract gap fully.