My init set fill-column for exactly one buffer

Count them before fixing anything. This gives the number of buffers holding their own value.

(seq-count (lambda (b) (local-variable-p 'fill-column b))
           (buffer-list))

If the answer is 1, it's the init line. If it's more, something else is setting it locally too, and setq-default won't change those buffers either.

The way I keep it straight is two questions in order. First, which value does a new buffer read? The default, so that's the one the init file has to set. Then, which buffers already have a local value? Those keep it, whatever the default says afterwards. It's close to a Python class attribute and an instance attribute, with setq-default setting the class attribute and setq on an automatically buffer-local variable assigning on the instance.

The analogy holds for fill-column and breaks one variable over. Take an ordinary variable, one nobody marked with make-variable-buffer-local. With no local value in the current buffer, setq sets the global value and every buffer sees it. In Python an assignment through an instance always lands on the instance. So whether setq behaves like self.x = 1 or like Cls.x = 1 depends on a declaration somewhere else in the source, which is exactly the sort of quiet cleverness I'd like the help buffer to keep shouting about.

One point on the scope of the fix. setq-default sets the default value and leaves existing local values alone. It corrects buffers created after the init line runs, while a buffer that already has a local fill-column, here *scratch*, keeps whatever the earlier setq or a mode gave it. For a clean result in the running session, that stale local value has to be removed with kill-local-variable in the buffer concerned.

Same thing got me in a commit message buffer. M-q wrapped at 70 there and at 72 in *scratch*, and I spent a while blaming the commit mode, which never had a local value at all.

Ran it. 3, not 1. *scratch* from the init line, plus two buffers where a mode hook of mine was doing a plain setq on it. C-h v in one of those shows the split too, the local value for that buffer and the global value next to it, which is quicker than the count once you already suspect a particular buffer. The hooks now use setq-local, so the intent is written down where it happens.

Fair, and the help buffer does shout, just only after you go and look. Inside code my answer is setq-local (it makes the variable local first and then sets it, whatever the declaration says), so a reader doesn't need to know the declaration at all. In the init file I've moved the per-buffer ones to setq-default, kept plain setq for the rest, and put a short comment next to the odd ones.

That bit me while testing, in the other direction. I tried (setq-default fill-column 80) from *scratch* to watch the effect, and *scratch* itself stayed at 72 because of the local value the init had given it. M-x kill-local-variable there, and it went to 80 straight away. (Restarting would have done it as well, but I had too many buffers open to want that.)