[BUG] Race: a concurrent new failure for the same key is silently dropped between a successful retry's accept() and remove()

## Description
`doRetry` performs two non-atomic steps: `registerRepository.accept(key)` (persist; on success the data is now in admin), then `registerRepository.remove(key)` (drop the holder). A `persist*` call that fails *between* those two lines calls `addToFail(key)`, finds the still-present (pre-`remove`) entry, and returns early — so no retry task is scheduled for the new failure. `doRetry` then calls `remove(key)`, wiping the holder. The new failure now has neither a holder nor a timer task.

## Location
```
shenyu-register-client-api/.../retry/FailureRegistryTask.java:54-58
shenyu-register-client-api/.../FailbackRegistryRepository.java:175-184, 200-222
```

## Impact
Lost registration of a legitimately-failing re-publish, under a narrow concurrency window. Compounds the failback-exhaustion issue.

## Suggested fix
Make the retry-success and re-add paths atomic, e.g. `concurrentHashMap.compute(key, ...)`, or have `doRetry` re-check after `remove` whether a re-add is needed.

## Related existing issue(s)
None

_Identified during the 2026-08-02 audit; full list in [`docs/issue-candidates-2026-08-02.md`](docs/issue-candidates-2026-08-02.md)._

Start with shenyu-register-client-api/.../retry/FailureRegistryTask.java:54-58, then read FailbackRegistryRepository.java:175-184 and 200-222 to trace accept, remove, and addToFail. Reproduce or reason through a failure arriving between the successful retry and removal. Done means that concurrent re-publish failures retain a holder or scheduled retry instead of being silently dropped.

Written by the indexing model from the issue text.