new-hist currently fails if the target history archive is already initialized, which makes repeated startup workflows awkward in dynamic environments. This change adds an explicit idempotent mode so operators can safely run archive initialization multiple times.

• CLI

  • Adds --idempotent to stellar-core new-hist
  • Preserves existing behavior by default; repeated initialization still fails unless the flag is set

• History archive initialization

  • Threads the idempotent option from command-line handling into initializeHistories(...)
  • Extends HistoryArchiveManager::initializeHistoryArchive(...) with an idempotent mode
  • Treats an existing .well-known/stellar-history.json as success when idempotent mode is enabled

• Coverage

  • Adds a focused history test that verifies:
    • first initialization succeeds
    • second initialization succeeds when idempotent mode is requested
    • existing non-idempotent behavior remains unchanged

• Docs

  • Updates the command reference for new-hist to document --idempotent

Example:

stellar-core new-hist --idempotent my-archive

This allows startup automation to ensure a history archive exists without needing wrapper logic to suppress an expected "already initialized" failure.