Ignore a leftover builds.maxConcurrent instead of refusing to start

The concurrency limit moved to executor.maxConcurrent without an alias, so
the old key binds a scalar where a build definition belongs and failed the
whole configuration. But that configuration is committed in the watched
repository, and a repository's master is not always changeable right away —
an installation must not be stuck on a key it is meant to forget.

A `builds` entry that is not a mapping is now dropped with a warning (once
per key, the config is loaded every poll cycle), naming executor.maxConcurrent
for the key that moved.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

src/main/resources/templates/releases.html

@@ -23,8 +23,9 @@
             <li><strong>Changed:</strong> the build concurrency limit moved from
                 <code>builds.maxConcurrent</code> to <code>executor.maxConcurrent</code> (default 1,
                 no compatibility alias) — the <code>builds</code> section now holds build definitions
-                only. A leftover <code>builds.maxConcurrent</code> key is rejected as an invalid
-                build definition.</li>
+                only. A leftover <code>builds.maxConcurrent</code> key is ignored with a warning
+                instead of failing the configuration, so an installation keeps running until its
+                committed config can be updated.</li>
         </ul>
 
         <h2>v0.9.14 <span class="muted">— 2026-08-28</span></h2>