fix(#511): raise completion generation cap to 5 to match Nexus-new loop

[James3014]

Part of #511 (host side of James3014/Nexus-new#1384). This PR fixes only gap 1, the generation budget, so #511 stays open for gap 2.

Base: nexus/connector-host-v1@528dc50a · Head: 4360d0b3

What changes

• New MAX_COMPLETION_INTEGRATION_GENERATIONS = 5 in src/github-completion-host.ts. It mirrors Nexus-new MAX_INTEGRATION_GENERATIONS / DEFAULT_MAX_INTEGRATION_GENERATIONS (main 7e1e3452).
• That one constant drives:
  • the parseGitHubCompletionToolInput default and max (was 3)
  • both port generation guards in materialize_integration_head and read_required_checks, through the new exported parseCompletionGeneration (was positiveInt(..., 3))
  • the github_complete_pull_request schema maxGenerations .max() and its "at most N" description in src/nexus-gateway-proxy.ts
• scripts/github_completion_bridge.py: the fallback max_generations changes from 3 to 5. The host always sends this value; the fallback is only a backstop.
• revalidate_affected_dimension does not change. Every dimension, TEST_IMPACT included, still fails closed with requires_fresh_candidate_acceptance: true.

RED, then GREEN

• RED on 528dc50: github-completion-host.test.ts failed on the missing export, and the proxy schema test failed with actual: 3, expected: 5.
• GREEN: npm run typecheck is clean and npm test passes (exit 0).

Why TEST_IMPACT revalidation is not in this PR (design questions)

Doing it safely is not a bounded host change. The Nexus-new contract needs answers first:

1. Order. The loop calls port.revalidate_affected_dimension(...) before materialize_integration_head, so the exact integration head I_n does not exist yet. The host could test a locally computed merge-tree(last_produced_head, new_main) tree. But the receipt binds only old/new_main_sha and source_candidate_*, and the loop never checks a revalidation tree against mat_result.integration_tree_sha. Passing would therefore not be mechanically bound to the head that gets checked and merged. Options: move the hook after materialization, or add integration_tree_sha to DimensionRevalidationReceipt and have the loop compare them.
2. Selection. requalify_main_movement returns TEST_IMPACT with only a fixed reason string. It does not expose the build_impact_plan(...).pytest_targets it computed, and the bridge passes no target list. If the host computed its own selection, a second selection authority would appear. The selection should come from Nexus-new, either in the dimension result or in the hook parameters.
3. Environment. TEST_IMPACT fires on pyproject.toml / uv.lock changes. The host runs pytest with a fixed NEXUS_PYTHON_BIN venv, which would be stale for exactly those movements. Who builds or attests the environment for the new lockfile? Or should dependency changes stay fail-closed?
4. Overlap with CI. Exact-head required checks already run on I_n before CAS merge. Should the TEST_IMPACT receipt be a host-side pytest run, or a typed delegation to "the required checks for the selected targets on I_n"? The second would need no host test runner, but it does change the loop contract.

Note for review (not changed here)

The port guard caps the absolute generation (current_generation + 1). The loop, however, budgets relative to start_generation. When a PR is already at I3 and a later loop run starts, it gets only two more generations before the host rejects I6, even though the loop would allow five. That is the same behaviour as before, with a higher ceiling. Making it relative would need the host to learn start_generation.

No merge, deploy, rebuild or runtime activation is part of this PR.

🤖 Generated with Claude Code