Document error propagation behaviour and update Config godoc

Closes the final acceptance criterion gap for team-tasks #4382 by making the error propagation contract explicit in the public API docs.

Changes

• BooleanValueDetails and StringValueDetails godoc: explicit statement that defaultValue is always returned on failure and errors are propagated for caller observability
• doc.go: new # Error handling section explaining the three guarantees (safe default, observable error, automatic logging when Logger is configured)

Design decision: Option A (errors propagated, not swallowed)

The PREP acceptance criterion said "without propagating an error to the caller" — this MR documents that we deliberately chose the opposite: errors are propagated because:

1. Callers who care about observability can inspect them
2. The package now also logs automatically when Config.Logger is set
3. defaultValue is always safe to use regardless — callers can ignore the error if they choose

Test plan

• go test ./featureflag/... -count=1 — all pass
• go doc gitlab.com/gitlab-org/labkit/v2/featureflag shows the Error handling section

---

Stack (merge in order)

#	MR	Status
1	!485 (merged) — Add httptest slow-server timeout test	merge into master first
2	!486 (merged) — Add slog.Logger observability	retarget to master after !485 (merged) merges
3	!487 (merged) — Document error propagation ← you are here	retarget to master after !486 (merged) merges