feat(agent): add task completion hook with bounded exits and explicit terminal states (T36)

[XianReallyHot-ZZH]

确认 (Acknowledged) contribution to ARGI: add the opt-in TaskCompletionHook completion predicate with bounded nudge/deadline exits and explicit NEED_INPUT/STOP terminal states as the second T36 slice for #139.

[Aias00]

Approved.

Clean, well-engineered opt-in hook for the T36 task-completion work. The routing logic is sound and the tests pin every branch:

• beforeModel establishes the message baseline once per run and clears any stale terminal decision (verified by the same-thread recovery test); the unknown-tool bound is enforced here by counting unresolved tool messages added since the baseline.
• afterModel implements the bounded nudge loop: it applies the nudge budget (maxAttempts) and optional deadline first, classifies NO_PROGRESS vs UNFINISHED_REQUIRED_TASKS by whether the answers were identical, then the independent REPEATED_DECISION bound (maxConsecutiveRepeats) on identical consecutive fingerprints, and finally resets the nudge counter on any productive tool call. I traced all four termination paths against the offline/deadline/stream tests and they line up.
• All counters live in config.context() and never enter the checkpointed state (asserted by runScopedCountersNeverEnterTheCheckpointedState); the only declared state key is the terminal decision with REPLACE strategy.
• ActionReasonCodes gains the four new bounded-exit labels with a stability test asserting 7 unique values; the new NO_PROGRESS / REPEATED_DECISION / UNKNOWN_TOOL / UNFINISHED_REQUIRED_TASKS reasons are covered.

Non-blocking nits (no action needed to merge):

1. Test package split is inconsistent: TaskCompletionHookTest and TaskCompletionHookDeadlineTest live in hook.taskcompletion (singular) while TaskCompletionHookOfflineTest and TaskCompletionHookStreamConsistencyOfflineTest live in hooks.taskcompletion (plural). Harmless since they only touch public API, but worth aligning.
2. decisionFingerprint uses message.text() for final answers; two null-text assistant turns would compare as identical and trip the repeat bound. Unlikely in practice (assistant turns carry text), but a defensive null check would harden it.

All CI jobs (build, test, check-style, format, license, linter, secret-check) pass. Good to merge.

[XianReallyHot-ZZH]

Thanks for the thorough review! Addressed both nits in a72feac:

1. Test package layout — TaskCompletionHookTest already lives in hooks.taskcompletion with the other public-API tests; the only split is TaskCompletionHookDeadlineTest, which deliberately stays next to the main class because it exercises the package-private nanoTime seam — the same layout as EffectAwareToolRetryInterceptorTest. Its javadoc now documents this so the split reads as intentional.

2. decisionFingerprint null hardening — now normalizes with Objects.requireNonNullElse. For the record, ChatMessage.text() joins content parts and cannot return null today (Collectors.joining contract), so the collision was theoretical; the normalization closes it regardless. Two new tests pin the semantics either way: identical textless assistant turns still count as repeats (textlessAssistantAnswersStillCountAsRepeatsWhenIdentical), while a literal "null" answer does not collide with a textless turn (textlessAnswerDoesNotCollideWithALiteralNullAnswer).

All 29 task-completion tests green; full module suite unchanged (only the Windows-local symlink cases that also fail on clean main).