Fix dead links in the docs

akka-docs/src/main/paradox/actors.md

@@ -265,7 +265,7 @@ calling the constructor manually:
 ### Dependency Injection
 
 If your `Actor` has a constructor that takes parameters then those need to
-be part of the `Props` as well, as described [above](Props_). But there
+be part of the `Props` as well, as described @ref:[above](#props). But there
 are cases when a factory method must be used, for example when the actual
 constructor arguments are determined by a dependency injection framework.
 

akka-docs/src/main/paradox/stream/operators/RestartSink/withBackoff.md

@@ -17,7 +17,7 @@ Wrap the given @unidoc[Sink] with a @unidoc[Sink] that will restart it when it f
 This @unidoc[Sink] will never cancel, since cancellation by the wrapped @unidoc[Sink] is always handled by restarting it.
 The wrapped @unidoc[Sink] can however be completed by feeding a completion or error into this @unidoc[Sink]. When that
 happens, the @unidoc[Sink], if currently running, will terminate and will not be restarted. This can be triggered
-simply by the upstream completing, or externally by introducing a [[KillSwitch]] right before this @unidoc[Sink] in the
+simply by the upstream completing, or externally by introducing a @unidoc[KillSwitch] right before this @unidoc[Sink] in the
 graph.
 
 The restart process is inherently lossy, since there is no coordination between cancelling and the sending of

akka-docs/src/main/paradox/typed/persistence.md

@@ -144,7 +144,7 @@ where resilience is important so that if a node crashes the persistent actors ar
 resume operations @ref:[Cluster Sharding](cluster-sharding.md) is an excellent fit to spread persistent actors over a
 cluster and address them by id.
 
-The `EventSourcedBehavior` can then be run as with any plain typed actor as described in [actors documentation](actors-typed.md),
+The `EventSourcedBehavior` can then be run as with any plain typed actor as described in @ref:[actors documentation](actors.md),
 but since Akka Persistence is based on the single-writer principle the persistent actors are typically used together
 with Cluster Sharding. For a particular `persistenceId` only one persistent actor instance should be active at one time.
 If multiple instances were to persist events at the same time, the events would be interleaved and might not be