CASSANDRA-16047 Keep SSTables referenced while linking them for incremental backup

[cheeeee]

CASSANDRA-16047 reports NoSuchFileException from createHardLink during incremental backup, which the
disk failure policy turns into an FSWriteError and a node shutdown.

Tracker.addSSTables publishes new readers into the live set before linking them into backups/, and holds
no reference while linking. A compaction that picks the reader up in between can obsolete and delete its
files while createLinks is still iterating the components; the exists() check before each link does not
close that window.

Changes:

• Tracker.maybeIncrementallyBackup takes a Ref on each reader (tryRef) for the duration of createLinks.
  A reader whose lifecycle has already ended (tryRef returns null) is skipped as a whole; components are
  never skipped individually.
• SSTableReader.createLinks: a missing component is skipped only if the format regenerates it on load
  (BIG: FILTER, SUMMARY; BTI: FILTER). Any other missing component throws
  UncheckedIOException(NoSuchFileException) rather than silently producing a link set that cannot be
  loaded. This is a behaviour change: a snapshot or backup of an SSTable that is missing a required
  component now fails with a plain exception (not an FSError, so the disk failure policy is not
  involved) instead of succeeding with an incomplete copy.

Testing (SSTableReaderTest, both fail without the change):

• testIncrementalBackupPinsComponentsUntilLinked: a Mockito spy releases the reader's own last reference
  the moment createLinks starts; every backed-up component must still match the original byte for byte,
  and the deferred deletion must run only after the Tracker releases its reference. Without the change
  it fails with NoSuchFileException on a Statistics component.
• testCreateLinksSkipsRegenerableComponentButFailsOnMissingRequired: a missing FILTER is skipped and the
  remaining components are linked; a missing STATS throws.

CASSANDRA-16047