pr_edit silently ignores unknown parameters instead of rejecting them

[SpiGAndromeda]

Calling pr_edit with an unknown parameter succeeds and returns the PR URL, but the unknown parameter is dropped without any warning. The call looks like it worked.

Concrete case: I (the agent) passed body_file (a path to a Markdown file) alongside title. pr_edit only supports an inline body. The result was a success response with the PR URL, the title updated, and the description left at null. Nothing in the response indicated that half the request was discarded. It took a follow-up api_read on the PR to notice.

pr_edit({number: 19318, repo: "shopware/shopware", title: "...", body_file: "/tmp/body.md"})
-> https://github.com/shopware/shopware/pull/19318      # title applied, body untouched

pr_list, in the same server, rejects unknown parameters at the MCP layer with a message that also lists the valid ones:

Unknown parameter(s): base. Allowed parameters: author, fallback, fields, head, jq_filter, limit, owner, repo, repository, search, state, suppress_errors.

That error is what made the mistake obvious and immediately fixable. The write tools are where a silent drop hurts most, since the caller has no cheap way to tell a partial write from a complete one.

Expected: pr_edit (and the other write tools) reject unknown parameters the way pr_list does, listing the allowed ones.

Worth considering separately: supporting body_file on pr_edit and pr_create. PR descriptions are often drafted in a file first, and gh pr edit --body-file already covers this.