There's a chance that it's a bug, but overall, theorems tend to be less true in real life than they are on the chalkboard. But it's pretty understandable that people get confused when suddenly a major theorem of math seems to have stop being true.

There are three things you should check in a case like this:

(1) You're comparing two indefinite integrals that should be equal, but remember they can differ from each other from a constant value. In highschool they force students to add the "+C" invisible constant everywhere, but in college they handwave this away most of the time and people get a bit casual. If this happens to be the case, there's no reason to be embarrassed - this even seems to occasionally slip the minds of active math professors at major universities.

(2) The results might contain inverse functions with branch-cuts. And maybe those branch-cuts aren't doing what you expect.

(3) Integration is done with "generic equality". That means it allows for the values to be considered equal if they only differ from each other at a set of points. We use generic equality when we say things like:

"The integral of x^n is x^(n+1)/(n+1)"

This statement isn't really true for when n is -1. We say it anyway understanding that it's generically true and because sometimes listing out all of the exceptions would be really infeasible. Integrals in Mathematica do the same thing. You can check by looking at the integral of x^n.

So I would begin to look at this by actually writing out the two integrals that define both convolutions and looking at their results. Probably also by plotting their results and comparing them.

The theory stands up fine in this case. But we are doing a convolution on functions that do not satisfy the integration formulation (so it is really an extension). In such cases Convolve will use Integrate and of necessity will have to set GenerateConditions->False since otherwise Integrate will see a divergence and return unevaluated. With GenerateConditions->False we have opened the door to various badnesses, unfortunately, since the integration range is likely to be split into to parts (-infinity to 0 and 0 to infinity), and possibly conflicting assumptions might be made quietly in handling each part.

The issue is under investigation but it's not clear how much improvement is to be had for examples where the integral in question is not unconditionally convergent.

I agree it may well have something to do with that, but I'm not an expert either. However, when I use an alternative method to calculate the convolution, it yields a result which I believe is correct (and this 3rd result is unequal to both results given by the Convolve function) --- and it finds this correct result despite the not-absolutely-integrable character you note, and it does this even though FourierTransform is based on integration:

fp = {0, -2 \[Pi]};

convolution3[s_] := 
 Evaluate[FourierTransform[
   Evaluate[
     InverseFourierTransform[f1, x, t, FourierParameters -> fp]]*
    Evaluate[
     InverseFourierTransform[f2, x, t, FourierParameters -> fp]], t, 
   s, FourierParameters -> fp]]

The Convolution Theorem tells us that expression should yield the convolution. Of the three competing results yielded by Mathematica, I'm pretty sure convolution3 is the correct one. Not an expert, but I have a textbook by an expert which indicates convolution3 is the right answer.