Deprecate CDS public API

Automate the standard CDS deprecation workflow for symbols exported from packages/web, packages/mobile, packages/common, packages/web-visualization, or packages/mobile-visualization.

Inputs to confirm first

1. What is being deprecated? Component name, hook, prop, or other exported symbol.
2. What should consumers use instead? The replacement must be named in JSDoc and in docs warning text.
3. Which major should @deprecationExpectedRemoval use? (e.g. v9, v10.) Ask the user to confirm if they have not already stated it. If they want a default, suggest the next major from the relevant package.json (see Step 2) and confirm they accept it before editing.

Step 0 — Discover every public export (all packages)

Deprecate the symbol everywhere it is publicly reachable, not only where it is first implemented.

1. For each CDS package (web, mobile, common, web-visualization, mobile-visualization), trace the symbol from that package’s package.json exports map → barrel / index files → the module that declares or re-exports the symbol.
2. Grep for the symbol name under packages/<name>/src (e.g. export { Foo, export * from, Foo as) to catch re-exports and alternate entry paths.
3. Every package that publicly exports the symbol must end up with deprecation coverage: primary implementation and any re-export site where your tooling or consumers would not see JSDoc from the source file (add JSDoc on the re-export line or duplicate the tags as needed so imports from @coinbase/cds-web, @coinbase/cds-mobile, @coinbase/cds-common, etc. all surface the deprecation).