Forgery attack on Poly1305 when the key and nonce reused
In Poly1305

16-byte AES key k
16-byte additional key r
16-byte $n$ nonce

is required. The obligations of the users


Any protocol that uses Poly1305-AES must ensure unpredictability of the secret key $(k, r)$.
The sender must never use the same nonce for two different messages


The obvious attack is the crib-dragging that destroys confidentiality and this doesn't mean that the encryption key is revealed. And this is not the case.
The nonce for Poly1305 is calcualted as $nonce = \operatorname{AES}_k(n)$
$$\operatorname{Poly1305}( r, m, \operatorname{AES}_k(n))$$
The $r$ actually $\in \{ 2^{106} \}$ not a full 128-bit.
The Poly1305 authentication can be simplified as
$$(((c_1 r^q + c_2 r^{ q−1} + \cdots + c_q r^1 ) \bmod 2^{130} - 5) + \operatorname{AES}_k(n)) \bmod 2^{128}$$ where $c_i$'s are encoded message $m$, $r_i$ is the $r$ in bytes.
OPs case
if we omit the $\operatorname{AES}_k(n)$ for pure Poly1305 then the equation becomes
$$(((c_1 r^q + c_2 r^{ q−1} + \cdots + c_q r^1 ) \bmod 2^{130} - 5) \bmod 2^{128}$$
Now, for simplicity only consider a small message that has 16-bytes and the same key and nonce is used. Then the for loop inside the while loop will work only once.
void poly1305_gmpxx(unsigned char *out,
    const unsigned char *r,
    const unsigned char *s,
    const unsigned char *m,unsigned int l)
  {
    unsigned int j;
    mpz_class rbar = 0;

    for (j = 0;j &lt; 16;++j)
        rbar += ((mpz_class) r[j]) &lt;&lt; (8 * j);

    mpz_class h = 0;
    mpz_class p = (((mpz_class) 1) &lt;&lt; 130) - 5
    
    while (l &gt; 0) {
        mpz_class c = 0;
        for (j = 0;(j &lt; 16) &amp;&amp; (j &lt; l);++j)
            c += ((mpz_class) m[j]) &lt;&lt; (8 * j);
        c += ((mpz_class) 1) &lt;&lt; (8 * j);
        m += j; l -= j;
        h = ((h + c) * rbar) % p;
    }   
    //Omitted since Pure Poly!
    //for (j = 0;j &lt; 16;++j)
    //    h += ((mpz_class) s[j]) &lt;&lt; (8 * j);

    for (j = 0;j &lt; 16;++j) {
        mpz_class c = h % 256;
        h &gt;&gt;= 8;
        out[j] = c.get_ui();
    }
}

then we have
mpz_class h = 0;
mpz_class c = 0;
for (j = 0; j &lt; 16 ;++j)
    c += ((mpz_class) m[j]) &lt;&lt; (8 * j);

h = (c * rbar) % p;

for (j = 0;j &lt; 16;++j) {
    mpz_class c = h % 256;
    h &gt;&gt;= 8;
    out[j] = c.get_ui();
}

The last loop actually outputs the 16 bytes of the $h$, since $p = 2^{130}-5$ is slightly less than the modulus.
Hint: play with the message, especially the upper part.
Note: rfc8439 replaced  RFC 7539

RFC 7539, the predecessor of this document, was meant to serve as a
stable reference and an implementation guide.  It was a product of
the Crypto Forum Research Group (CFRG).  This document merges the
errata filed against RFC 7539 and adds a little text to the Security
Considerations section.