Summary

Fixes #62965

@deprecated JSDoc tag on a getter or setter no longer marks the property as deprecated in completions or suggestion diagnostics when only one accessor of the pair has the tag. This is a regression introduced in #41941.

Problem

Getter/setter pairs share a single symbol with two declarations. PR #41941 changed the deprecation check to require all declarations to be deprecated (using every()), which is correct for function overloads but incorrect for accessor pairs. If only the getter has @deprecated, the property should still appear deprecated when reading it — and vice versa for the setter.

Three locations needed fixing:

1. src/compiler/checker.ts — isDeprecatedSymbol(): For symbols with SymbolFlags.Accessor, use some() instead of every() to check declarations, matching the existing behavior for interface members.

2. src/services/completions.ts — isDeprecated(): Same fix — use some() for accessor symbols so completion items get the deprecated sort text.

3. src/services/symbolDisplay.ts — getNormalizedSymbolModifiers(): The existing logic strips the deprecated modifier when the first declaration is deprecated but others aren't. For accessor symbols, re-add the deprecated modifier if any declaration has @deprecated.

Tests

• completionsWithDeprecatedGetterSetter.ts — verifies deprecated kindModifiers and sortText in completions for getter/setter pairs where only one accessor has @deprecated
• jsdocDeprecated_suggestionGetterSetter.ts — verifies suggestion diagnostics (strikethrough) for the same scenarios

All existing completionsWithDeprecatedTag* and jsdocDeprecated_suggestion* tests continue to pass.

Disclosure

This PR was authored with the assistance of Claude (LLM) to help understand the codebase and structure the implementation and description.