docs(15.9): restart OpenSearch after restoring configsync so the dictionaries are written

[marevol]

Summary

Follow-up to #542. The snapshot restore procedure restores configsync, calls _configsync/flush, then restores fess*. That only works when the new OpenSearch node was started moments before. On a node that has been up for more than about a minute, the flush writes no dictionary files, fess* restores into a red cluster (IOException while reading mappings_path: file not readable), and the "cluster is red after restore" recovery fails the same way.

Cause

In opensearch-configsync 3.8.0 and earlier (the version in the fess-opensearch:3.8.0 image), _configsync/flush and the scheduled updater share one per-node watermark. Each run searches for files with @timestamp at or after the watermark and moves the watermark to its own start time. Restored files keep the timestamps from the source cluster, so after the first scheduled run (about a minute after startup) neither a flush nor the updater selects them. The file is written only when missing or older than its @timestamp, which does not matter here because it is never selected.

A restart resets the watermark, so a flush right after it writes every stored file. opensearch-configsync#18 (on main, not in a release yet) makes a flush read every stored file, which also fixes this; the restart is harmless there.

Changes

<lang>/15.9/config/admin-index-backup.rst, all seven languages:

• "Restoring all indexes" step 2: restart OpenSearch (every node), wait for the configsync index, then _configsync/flush. A note explains why the restart is needed and that each written file is logged as Updated <path> by ConfigSyncService.
• "Cluster is red after restore" step 1: says the restart is part of steps 1 and 2. The wait uses _cluster/health/configsync, which returns while the rest of the cluster is still red.

Verification

Single-node fess-opensearch:3.8.0, a snapshot of configsync plus an index whose analyzer reads two dictionary files through mappings_path and stopwords_path, restored on a fresh node about 95 seconds after it started:

Procedure	Files written	After restoring the index
restore configsync, flush (current docs)	0 (still 0 after 70 s more)	red, 1 unassigned shard
restore configsync, restart, wait, flush (this PR)	2	green, analyzer applies both files
red-cluster recovery: restart, flush, close, restore again	2	green

The same plugin built from opensearch-configsync main wrote both files with flush alone and with restart + flush.

Multi-node clusters were not tested; the restart applies to every node because the watermark is kept per node.