Code written by WriteSourceFile has nullable disabled: every string? it emits raises CS8669, and non-annotated members are null-oblivious to consumers #55

What's wrong

GeneratorBase.WriteFileHeader (SourceGeneratorToolkit/GeneratorBase.cs, around lines 133–147) writes the copyright lines, then // <auto-generated />, then a blank line. WriteSourceFile (around lines 158–164) then calls codeBlocker.AddSourceFile(...) immediately.

Nothing on this path writes a #nullable directive. CodeBlocker.AddSourceFile emits the namespace, usings and types, but not #nullable enable; CodeBlocker has a separate WriteNullableEnable() for that.

Roslyn treats any file carrying an <auto-generated marker as generated code. Generated code runs with the nullable context disabled unless the file opts in with a directive, whatever <Nullable>enable</Nullable> the consuming project sets. And because WriteSourceFile writes the header and the body in one call, a caller can't put the directive between them.

Failure scenario

A generator built on the toolkit writes a class through WriteSourceFile with public string? Description; and public string Name = "";. The output is:

// Copyright (c) 2023-2026 ktsu-dev contributors
// <auto-generated />

namespace Generated;

public class Thing
{
	public string? Description;
	public string Name = "";
}

That output is compiled with NullableContextOptions.Enable alongside a user file containing t.Name = null; int n = t.Description.Length;. The compiler reports:

Thing.g.cs(8,15): warning CS8669: The annotation for nullable reference types should only be used in code within a '#nullable' annotations context. Auto-generated code requires an explicit '#nullable' directive in source.
User.cs(1,75): warning CS8602: Dereference of a possibly null reference.

t.Name = null produces no CS8625, because Name is nullable-oblivious.

Consequences:

• With TreatWarningsAsErrors, which ktsu repositories use, any consuming generator that emits a ? annotation breaks the consumer's build.
• Without annotations, every reference-typed member in the generated API is oblivious, so consumers silently lose null checking on it.
• The harness can't catch this today, because it never compiles generated output (GeneratorHarness can't tell whether generated sources compile: a duplicate type across two generated files, or a reference to a missing type, comes back with 0 diagnostics #50).

Suggested fix

Have WriteFileHeader write #nullable enable after the // <auto-generated /> marker, so WriteSourceFile inherits it. Alternatively, add a parameter or overload that opts in. Enabled-by-default suits the ktsu convention of nullable-enabled projects.

Acceptance criteria

• The output of WriteSourceFile and WriteFileHeader contains #nullable enable after the generated-file marker, or does so when the new option is chosen.
• A test compiles WriteSourceFile output that contains a string? member under nullable enable and asserts there is no CS8669.
• A test asserts that assigning null to a non-annotated generated string member raises CS8625.