GL: expand notes for the "nv-broken-buffer-dsa" workaround.

doc/changelog.dox

@@ -250,7 +250,8 @@ See also:
     @ref opengl-workarounds for more information.
 -   A new @cpp "nv-broken-buffer-dsa" @ce workaround for a rendering corruption
     on NVidia 572.82 drivers happening when DSA codepaths for @ref GL::Buffer
-    are used. See @ref opengl-workarounds for more information.
+    are used. See @ref opengl-workarounds for more information. See also
+    [mosra/magnum#676](https://github.com/mosra/magnum/issues/676).
 -   A new @cpp "nv-framebuffer-invalidation-wants-draw-binding" @ce workaround
     for @ref GL::Framebuffer::invalidate() affecting unrelated framebuffers on
     NVidia. See @ref opengl-workarounds for more information.

src/Magnum/GL/Implementation/driverSpecific.cpp

@@ -230,10 +230,11 @@ constexpr Containers::StringView KnownWorkarounds[]{
 
 /* On NV driver 572.83 and likely 566.24 as well, DSA buffer APIs don't work.
    This was reported on Windows with a NVIDIA RTX 2000 ADA generation graphics
-   card, and downgrading to 556.39 fixes that. On Arch, RTX 3050 and 570.86 it
+   card, and downgrading to 556.39 fixes that. A similar issue was reported
-   doesn't happen. Not sure if it's really specific to that GPU generation or
+   with A3000 on Windows. On Arch, RTX 3050 and 570.86 it doesn't happen. Not
-   it's just a regression in the platform-independent GL frontend that affects
+   sure if it's really specific to that GPU generation or it's just a
-   only some cards somehow.
+   regression in the platform-independent GL frontend that affects only some
+   cards somehow.
 
    The behavior is similar to the one explained below in the
    "intel-windows-crazy-broken-buffer-dsa" workaround (ImGui rendering