Add an optional confidence integer parameter (0–100) to update_issue_type,
update_issue_labels, and set_issue_fields MCP tools. The confidence score
is passed through to the REST/GraphQL API on mutation calls.

- Rename structs to WithIntent (labelWithIntent, issueTypeWithIntent)
- Add confidence schema property (integer, min 0, max 100) with prompt
  guidance describing what different confidence levels represent
- Update tool descriptions to encourage including confidence scores
- Pass confidence in the API request body alongside rationale/suggest

Closes github/plan-track-agentic-toolkit#219

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Today the server decides whether to route issue_write and create_pull_request
through the MCP App form using two implicit signals: _ui_submitted (set by
the form on submit) and a heuristic that bypasses the form when the call
carries any parameter the form cannot represent (labels, assignees,
issue_fields, state, reviewers, etc.). The model had no first-class,
documented way to say "execute directly, do not show a form".

Add a show_ui boolean parameter to the input schema of IssueWrite,
LegacyIssueWrite, and CreatePullRequest. It defaults to true and is
visible only to clients that advertise MCP App UI support: the strip
happens per-request in inventory.ToolsForRegistration via a new
stripUIOnlySchemaProperties helper, gated by the same predicate that
already strips _meta.ui (shouldStripMCPAppsMetadata). The two strips share
one decision so the schema and metadata stay in lock-step.

Form-routing predicate becomes:

    MCPApps FF on && client supports UI &&
    !_ui_submitted && show_ui && !hasNonFormParams

show_ui=false is a new explicit way for the model to opt out. The existing
non-form-param auto-bypass stays as a safety net, and the React forms keep
sending _ui_submitted=true on submit unchanged. get_me is out of scope
because its UI is pure client-side card rendering with no server-side
gating to replace.

The current strip gate ("strip when FF is off OR capability explicitly
absent") mirrors today's _meta.ui behavior exactly, including the
"capability unknown" case. For stdio that means UI-capable schemas are
exposed to any FF-enabled client. The handler-side clientSupportsUI check
still gates form execution at call time, so it is functionally a no-op for
non-UI stdio clients. A separate follow-up will tighten the gate to
"strip on unknown too" and wire an InitializedHandler in stdio to
re-register the un-stripped surface only after a UI-capable client has
advertised; the two changes must ship together to avoid breaking stdio.

docs/feature-flags.md and docs/insiders-features.md include an unrelated
"reviewers" description update picked up by script/generate-docs from
commit 2bd162a ("fix: support team pull request reviewers"), which
updated the source schema but did not regenerate docs.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The code comments next to the show_ui schema entries (and the
uiOnlySchemaProperties allowlist) said the property is documented in
"toolsnaps / README". README is generated from the stripped (non-UI)
schema, so show_ui is not actually in it — it only appears in toolsnaps
and the feature-flag / insiders docs. Reword the comments to match
reality.

Comment-only change; no behavior or test impact.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

The form-routing logic depends on a hand-maintained classification of
each schema property into form-resendable vs known-non-form. A new
property added without updating the classification would silently shift
UI gating behavior (e.g. a form-incompatible param wouldn't trigger the
safety-net bypass).

Add Test_issueWriteSchemaClassification and Test_createPullRequestSchemaClassification
that enumerate each tool's InputSchema.Properties and require every
property to be classified as exactly one of:
  - form-resendable (member of issueWriteFormParams / pullRequestWriteFormParams)
  - known-non-form (test-local allowlist)

A future schema addition without classification fails the test with a
message pointing at the exact set the contributor needs to update.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Previously `show_ui` was listed in docs/feature-flags.md and
docs/insiders-features.md alongside ordinary parameters with no
indication that it is hidden from clients without MCP App UI support.
A reader scanning the parameter list would assume it is always available.

Add a programmatic conditional-property mechanism:

- `inventory.ConditionalSchemaPropertyDescriptions()` exposes a
  map[propertyName]conditionDescription derived from the same
  uiOnlySchemaProperties allowlist that drives the per-request strip
  in ToolsForRegistration. Single source of truth.
- The doc generator (writeToolDoc) consults this map and appends
  "conditional — <description>" to the parameter's parenthesised
  type/required suffix.

Example rendered output:

  - `show_ui`: Whether to render the MCP App form... (boolean, optional,
    conditional — only visible to clients that advertise MCP App UI support)

A small test (TestConditionalSchemaPropertyDescriptions) ensures every
entry in uiOnlySchemaProperties has a description, so a future stripped
property addition can't silently lose its doc marker.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

- Rebase onto main (includes #2605 and #2600)
- Clarify form-params comments: show_ui is a routing flag, not form-collected
- Fix create_pull_request show_ui description (remove misleading reviewers example)
- Regenerate docs and toolsnap

Co-authored-by: Cursor <cursoragent@cursor.com>