Advertise form elicitation in client

[caseychow-oai]

Summary

Align client elicitation behavior with what is actually handled:

• advertise form elicitation support explicitly
• decline URL-mode elicitation requests

What Changed

• client/src/lib/hooks/useConnection.ts
  • changes client capabilities from elicitation: {} to elicitation: { form: {} }
  • adds URL-mode guard in the elicitation/create handler returning { action: "decline" }
• client/src/lib/hooks/__tests__/useConnection.test.tsx
  • updates capability expectation to assert elicitation.form
  • adds test coverage that URL-mode elicitation is declined and not forwarded to onElicitationRequest

Why

The client should only declare/support elicitation modes it can handle. This keeps capability advertisement and runtime behavior consistent.

Testing

• cd client && npm test -- --runTestsByPath src/lib/hooks/__tests__/useConnection.test.tsx --watch=false
• Result: pass (42 tests)

Breaking Changes

None.

AI Disclosure

This PR was prepared with assistance from an AI coding agent.

[cliffhall]

@caseychow-oai

• We're not advertising URL elicitation support yet, so we don't need code to respond to URL elicitation requests with a rejection. Servers should not be sending any such requests.
• We have a URL elicitation PR on deck, but there's an SDK issue holding up its counterpart, the Everything server PR for URL elicitation that we need for testing. We will roll those out together.
• We do support form elicitation, but don't need to explicitly say "form", as that's the default. The spec says:

For backwards compatibility, an empty capabilities object is equivalent to declaring support for form mode only:

{
  "capabilities": {
    "elicitation": {}, // Equivalent to { "form": {} }
  },
}