Give IconLibrary a name, and the server a way to report it (#111)

[ctgnz]

Closes #111.

Since #93 the server names no library — it runs against whichever one is on its classpath, which is what lets one build serve any of them. That left nothing able to say which one it actually got. With an instance per library planned, each on its own subdomain (#93, #112), "which library is this one running" needs to be answerable from outside rather than inferred from which symbol sets happen to turn up in a listing.

What's here

• IconLibrary.getName() — declared on the interface. Returns the library's own name: Standard, Hallux, BattleOrder.
• IconLibrary.ftl — emits it from the libraryPrefix the library was generated with, which is what names the class too, so a new library gets a correct name for free rather than having one to remember to set.
• /info/library on IconGeneratorController, returning a new LibrarySummary record — the name plus the symbol set count.
• DynamicIconLibrary (editor) and the test fixture answer Dynamic and Fake.

Deliberately not getVersion(). getVersions() already means something else on this interface — an APP-6 edition, SIDC positions 1–2 — and the singular/plural pair would read as one concept split in two. Noted in the javadoc so it doesn't get "tidied" later.

Verification

Both generated libraries were regenerated rather than hand-patched (per CLAUDE.md). git diff confirmed the only change in either was the new method, returning "Standard" and "Hallux" respectively.

Against the packaged server:

$ curl http://localhost:8081/info/library
{"name":"Standard","symbolSets":23}

mvn verify green across all seven modules — 84 tests, Spotless clean, both fragment checks clean (6,258 fragments, 0 off the shape).

🤖 Generated with Claude Code