fix(issues): accept native integer types for issue_number parameters

[syf2211]

Summary

Extend RequiredInt / toInt coercion to accept native Go integer types (int, int64, etc.) and json.Number, not only float64 and numeric strings. Also restore missing deprecated aliases for the issues consolidation rename.

Motivation

Fixes #2807. Some MCP clients (including mcpcurl when schema fields use integer, and other providers that construct argument maps programmatically) pass issue_number as a native integer. RequiredInt previously rejected these with expected number, got int before any GitHub API call was made.

Additionally, get_issue and update_issue were renamed to issue_read and issue_write in #1211 but aliases were never added to DeprecatedToolAliases, breaking users still referencing the old tool names.

Changes

• Add numericToFloat64 helper and route toInt / toInt64 through it
• Add deprecated aliases: get_issue → issue_read, update_issue → issue_write
• Add regression tests for int / int64 in RequiredInt and add_issue_comment

Tests

go test ./pkg/github/ -run 'Test_RequiredInt|Test_AddIssueComment' -v

All tests pass.

Notes

• composer-2.5 review: APPROVE
• Central fix in params.go benefits all tools using RequiredInt, not only issue tools

[e345ee]

Nice fix, this addresses the native int rejection.

One thing I’d consider tightening before merge: the new numeric path accepts int64/uint64/json.Number, but converts them through float64. That can lose precision for large integer values. Would it be worth preserving native integer types through validation and only using float parsing for actual float/string inputs?

It might also be useful to add regression coverage for all affected issue tools: issue_read, issue_write, and add_issue_comment, plus a no-API-call assertion for invalid issue_number on write tools.🥀 🥀 🥀 🥀