fix: Report the real error when the flag push request cannot be built

[keelerm84]

Summary

featureLoop builds its push request from a URI assembled at run time, so construction can
fail on a malformed SALESFORCE_URL. It answered that failure with a fixed string of its
own -- misspelled as Failed constructiong flag push request -- and discarded the error
http.NewRequest produced, which for a malformed URL is the only thing worth knowing. The
loop's poll already returns the underlying error, so the push now agrees with it.

The log line stays alongside the return, deliberately. run() reads one error from each
loop and returns only the first to arrive, so an error from this site reaches the operator
only when featureLoop wins that race. Measured with a malformed SALESFORCE_URL and a
200ms flag poll latency, eventLoop won 40 of 40 runs and the parse error appeared nowhere
at all. A comment records this, so the line is not removed again on the reasoning that the
return already carries it. (It was removed on exactly that reasoning in an earlier revision
of this PR, and a review caught it.)

Also fixes the neighbouring log line, which read failed pushings flags to salesforce. That
one prints a client.Do error, which net/http redacts via stripPassword, so its content
is unchanged.

Scope reduced since the first review

eventLoop's push had the same defect, and that half has since landed with #69, which
rewrote the surrounding block. Only featureLoop remains here.

The test covering eventLoop is kept rather than dropped: it now guards the version of that
code which arrived by the other route, and it still passes.

Tests

A test per loop. A control character is what url.Parse refuses, which is how each forces
the failure, and each asserts the failure is reached before asserting anything about it --
so a future stdlib that accepts these URLs fails loudly rather than passing vacuously.

Verified discriminating three ways: against the original fixed strings; against a same-base
parse error with a different suffix, so the assertion pins which URI is named rather than
merely that an error occurred; and against mutating only the return while keeping the log
line, which confirms the assertion is on the returned error rather than the log.

The expected text is derived from a live http.NewRequest call rather than hard-coded,
because the two toolchains render a DEL byte differently in %q output -- Go 1.15 uses the
Unicode escape form and 1.26 uses the hex form, and CI pins 1.15. Green on both, and under
-race -count=20 and -shuffle=on.

Information disclosure

Returning http.NewRequest's error means the raw URL reaches log.Fatal, and url.Parse
does not redact userinfo the way client.Do does. This was reviewed specifically and found
immaterial: the variables whose parse failures can leak all pre-set Authorization, so
userinfo in them is discarded by Go and that configuration cannot work; the one variable
where userinfo is functional (OAUTH_URI) has no reachable leak path; and the category
already exists on main independent of this change. Nothing more sensitive than the
configured URL can reach these errors -- the parse happens before the body is even
type-asserted, and every Header.Set runs after construction succeeds.