I agree, the max alpha should give zero coefficients.
Do you want to give it a try and open a PR?

The change policy might be tricky as it corresponds to changing a model (once fixed, ElasticNetCV.fit will give different results than before) and there is no meaningful deprecation path, IMO.
I consider it a bug fix such that no deprecation cycle is needed.

I could simply modify the function sklearn.linear_model._coordinate_descent._alpha_grid, but I'm not sure this would be optimal. I would simply be repeating the calculation of multiplying by sqrt(sample_weight) which is already being done when we fit ElasticNet.
Personally, here is how I would approach the problem:

(1) I would always make the ElasticNet model call enet_path. Surprisingly, this can be faster than the existing approach, even if we only want to solve for a single value of alpha. Consider the following timings from my own machine.

First we generate the data and the array of alphas:

from sklearn.linear_model import ElasticNet, enet_path
from sklearn.datasets import make_regression

X, y = make_regression(1_000_000, n_features=50, noise=0.1, random_state=0)
alphas, _, _ = enet_path(X, y)

Now we time the alternative approaches:

%%timeit
enet_path(X, y)

Output: 1.41 s ± 348 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

%%timeit
enet = ElasticNet(alpha = alphas[-1])
enet.fit(X, y)

Output: 1.58 s ± 281 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

(2) Thus, ElasticNet would accept an n_alphas parameter.
Now ElasticNetCV(n_alphas=n_alphas) will always begin by fitting ElasticNet(n_alphas=n_alphas). Then, to get the alphas to use for the different CV folds, we simply use the .alphas_ attribute of our ElasticNet.

Therefore, the normalization of X, y with respect to sample_weight will only happen once inside of ElasticNet, rather than once inside of ElasticNet and once inside of _alpha_grid.

I consider it a bug fix such that no deprecation cycle is needed.

I agree with that

I could simply modify the function sklearn.linear_model._coordinate_descent._alpha_grid, but I'm not sure this would be optimal. I would simply be repeating the calculation of multiplying by sqrt(sample_weight) which is already being done when we fit ElasticNet. Personally, here is how I would approach the problem:

I think it's better to first fix the issue, if there's the possibility of a simple fix as it seems here, with a good non-regression test like you showed in your issue. Then we can think about making some small refactorings in a separate PR.