build: check format strings, which nothing ever did

[Bitflash-sh]

Follow-up to #5. That segfault was a format string, and the compiler could have caught it — this makes sure the next one is caught.

What happened

%I64d is MSVC-only. glibc reads it as the GNU I flag, a width of 64, and an int conversion; the vararg run desynchronises and the following %s dereferences an integer as a pointer. It killed the node mid-sync, deterministically, at the first block carrying a real transaction.

GCC diagnoses this. It never got the chance, for two reasons that had to be fixed together — fixing either alone does nothing:

1. -w in both makefiles suppressed every diagnostic. It cannot be narrowed: it wins over any -W or -Werror= that follows, in any order. So it had to go. The four -Wno- entries replacing it are the categories this 2009-era tree actually produces — measured at 248 deprecated-declarations, 157 write-strings, 18 narrowing, 1 unused-result — silenced by name rather than wholesale.

2. No format attributes. Even with -Wformat on, GCC only inspects format strings for functions it knows are printf-like. Every format string in this project goes through strprintf, error, my_snprintf or OutputDebugStringF — and printf itself is #defined to the last of those. None carried an attribute, so the whole tree was invisible to the check. That is the real reason %I64d survived, and it is why enabling warnings alone would have changed nothing.

What it found

77 warnings across 17 distinct sites (the same header lines multiplied across translation units), all fixed here. Most were size_t or int64 passed to %d — harmless on x86-64, still wrong. Two were not cosmetic:

• CBlockIndex::ToString printed pprev/pnext with %08x, truncating both pointers to 32 bits. The two fields that line exists to show were unreliable on every 64-bit build.
• CInv::GetCommand threw "type=% unknown type" — the % ate the space as a flag and the u as its conversion, so the message read type= 3nknown type.

PRId64

Now one spelling for every target. Its MSVCRT branch is what produced "I64d" in the first place; it is pointless against UCRT, which takes the C99 forms; the rest of the tree already prints int64 with %lld on Windows; and its only user, i64tostr, is dead code. Collapsing it is what lets both builds share the gnu_printf archetype — ms_printf would reject %zu (used here, supported by UCRT) while waving through the %I64d that crashes.

Verification

Both platforms, clean build, then the specifier reintroduced on purpose:

main.h:410:50: error: unknown conversion type character 'I' in format
main.h:410:70: error: format '%s' expects argument of type 'char*',
                      but argument 3 has type 'long long int'

The second line is the crash itself, caught at build time instead of shipped.

Runtime on both platforms — node syncs past the issue #5 block, and the repaired log lines read correctly:

before:  CTxOut(nValue=                    50.%08I64d, scriptPubKey=(null))
after:   CTxOut(nValue=50.00000000, scriptPubKey=0xE1C7EF3E70600290DCEDB8)

• Linux: 0 warnings, 0 errors, synced to 1388 past block 1062
• Windows: 0 errors, binary runs and syncs
• %I64d reintroduced fails the build on both
• Log output verified correct on both

Known leftover

Four '_WIN32_WINNT' redefined warnings remain on Windows. Silencing them means letting a system header choose the Windows API level instead of this tree, which is a separate decision from format checking and does not belong in this PR.