Support standard OpenAPI methods

[kriptoburak]

Summary

• Register HEAD, OPTIONS, and TRACE operations from OpenAPI path items.
• Mark those safe methods read-only and idempotent in tool annotations.
• Add a CLI-backed regression test that confirms the methods appear in tools/list.

Why

OpenAPI supports these standard HTTP methods, but emcee previously skipped them during tool registration.

Validation

• go test ./...
• git diff --check

[mattt]

Hi @kriptoburak. Thanks for your contribution! I considered supporting HEAD, OPTIONS, and TRACE methods but decided against them. They're supported, but I've never personally seen them in an OpenAPI spec in the wild.

• HEAD is often implicitly supported wherever GET exists, but not documented as a separate OpenAPI operation
• OPTIONS is usually infrastructure/CORS behavior, not an application operation worth exposing as a tool
• TRACE is rare and often disabled outright

Do you have a specific API in mind that you're working with?

[kriptoburak]

Thanks for reviewing and for explaining the project direction.

I do not have a target-specific API that needs this in Emcee. This was a general OpenAPI compatibility patch, and your reasoning for keeping the method set narrower is fair. I am closing this to avoid keeping a weak-fit PR open.

[mattt]

@kriptoburak Thanks again for your contribution — I really appreciate it. If nothing else, it got me thinking about the recent IETF standardization of the QUERY method with RFC 10008, so I opened #65 to add support.