Improve diagnostic for @Flag Bool? without inversion:

[qflen]

Resolves #835.

Problem

When a user writes the following, which looks reasonable:

@Flag(help: "Write empty files.")
var writeEmptyFiles: Bool?

the compiler produces a confusing diagnostic:

error: referencing initializer 'init(name:help:)' on 'Flag' requires the types 'Bool?' and 'Int' be equivalent

The actual cause is that every Flag where Value == Bool? init requires an inversion: parameter. Without one, overload resolution falls through to the Flag where Value == Int counter initializer at Flag.swift:385, which is the first init(name:help:) the compiler can see, and the Bool? vs Int mismatch surfaces from there.

Fix

Add an @available(*, unavailable) init overload on Flag where Value == Bool? whose signature matches the offending call shape. Overload resolution now picks this one because its where clause is more specific, and the custom message: points the user at the real cause:

error: 'init(name:help:)' is unavailable: An optional 'Bool?' @Flag requires an 'inversion:' parameter, such as '.prefixedNo' or '.prefixedEnableDisable'.

This follows the same pattern used for the existing unavailable no-arg Flag.init() at Flag.swift:94-101, whose doc comment already explains this technique:

Explicitly marking this initializer unavailable means that when Value is a type supported by Flag like Bool or EnumerableFlag, the appropriate overload will be selected instead.

Test plan

• swift test passes (495 tests, no failures)
• Reproduced the original confusing error on main
• Verified the new diagnostic message appears for @Flag(help: "...") var x: Bool?
• Verified the legitimate usage @Flag(inversion: .prefixedEnableDisable) var x: Bool? still compiles and runs correctly

[rauhul]

I want @natecook1000's eyes on this as it affects the public api, albeit with an unusable symbol

[natecook1000]

Thanks, @qflen! LGTM with one minor change.