Fix FormatIface out-of-bounds writes and the InterfaceSearch hang

[makadore]

FormatIface writes out of bounds and mangles names, and InterfaceSearch on top of it can spin forever. Neither depends on the compiler; both reproduce under clang and GCC.

Names without a three digit suffix lose a character. The backwards scan stops on the last character instead of past it, so the version field is written one byte early and overwrites it. With the strlen(iface)+4 buffer ISmmAPI::FormatIface documents, ServerGameDLL comes back as ServerGameDL001, and a name shorter than the field is replaced outright — X becomes 001.

A trailing run shorter than three digits writes past the end. The size check asks for maxlength > strlen, while the write needs three digits and a terminator from where the digits start. ServerGameDLL5 into a 15-byte buffer puts two bytes past it; checked against a guard byte, ServerGameDLL55 and A1 do the same.

InterfaceSearch hangs on anything but a three digit suffix. It uses the return of FormatIface directly as its loop condition. FormatIface returns -1 when the version will not fit, -1 is true, so the loop calls the factory with an unchanged name and asks again, forever. It passes strlen+1, which is only ever enough for a name that already ends in three digits, so InterfaceSearch("ServerGameDLL", ...) and InterfaceSearch("ServerGameDLL5", ...) never return. Against a call cap:

input	master	after
ServerGameDLL005 -> ...008	found	found
VEngineServer021 -> ...023	found	found
ServerGameDLL	hangs	gives up
ServerGameDLL5	hangs	gives up
ServerGameDLL55	gives up	gives up

Tightening the size check makes FormatIface return -1 in one more case, which without the loop fix turns that last row into a hang too, so the two belong together.

Names ending in the usual three digits come out byte-for-byte identical, which covers every interface Metamod looks up itself. Verified on a HL2DM dedicated server: Metamod loads and SourceMod loads under it, identically before and after.

The third commit is separate: every failure path in _Load leaves a reason in the error buffer except the one where the plugin's own Load() returns false, so a plugin that refuses without setting a message is reported with no reason at all. With a plugin that does exactly that, on the same server:

before  [META] Failed to load plugin addons/metamod/bin/refuser:
after   [META] Failed to load plugin addons/metamod/bin/refuser: Plugin refused to load without giving a reason

Fixes #231.

One of the changes is only about GCC and you may not want it: std::unique_ptr<FILE, decltype(&::fclose)> trips -Werror=ignored-attributes, since glibc attributes fclose and an attributed type cannot be a template argument. CI has only ever run clang, so GCC is a configuration AMBuildScript handles but nothing tests, and master does not build with it — FormatIface's snprintf into a four-byte field was the other failure, which the fix above resolves anyway by formatting through a scratch buffer, truncating exactly as before. Happy to drop that commit if GCC is not something you want to carry.

Built and tested both ways: clang 18.1 and GCC 13.3, x86, against hl2sdk-hl2dm.