fix(client): prefer .title over .name for prompt, resource, and template labels (closes #1226, #1227)

[adityachilka1]

Closes #1226 and closes #1227 (two-for-one).

Why

The MCP spec's BaseMetadata gives every named entity an optional
attribute title, aimed explicitly at UI display:

Intended for UI and end-user contexts — optimized to be human-readable
and easily understood, even by those unfamiliar with domain-specific
terminology. If not provided, the name should be used for display.

The Tools tab already follows tool.title || tool.name (e.g.
client/src/components/ToolsTab.tsx:293). PromptsTab and ResourcesTab
(and the Resource Templates list) rendered the raw name.

Changes

• client/src/components/PromptsTab.tsx
  • Add title?: string to the local Prompt type (mirrors the SDK
    BaseMetadataSchema field).
  • List position: {prompt.name} → {prompt.title || prompt.name}
  • Selected header: selectedPrompt.name → title || name
• client/src/components/ResourcesTab.tsx
  • List position (resources): resource.name → title || name
  • List position (resource templates): template.name → title || name
  • Selected header + its title attribute: title || name for
    both selectedResource and selectedTemplate

The SDK-exported Resource and ResourceTemplate types already declare
title via BaseMetadataSchema, so no type changes were needed there.

No type changes for SDK-imported types

The local Prompt type in PromptsTab.tsx is hand-maintained and is where
the new field goes.

Verification

npm test -- --testPathPattern='ResourcesTab|PromptsTab'
npm run prettier-check

• 10 / 10 tests pass in ResourcesTab.test.tsx (no PromptsTab test
  file in the repo, so this is the closest coverage).
• prettier-check passes for the whole repo.

No behavioral regression

When title is absent (null | undefined | empty string), the || name
fallback kick in, returning the exact same string the UI previously showed.
Only change: when the server does provide a title, it's used.