Ich bin zwar eine andere Person, aber antworte dir trotzdem.

Mit "Upstream" meinst du den Code der Entwickler, also bspw. beim LibreOffice Projekt der Code, dem man von der Projektwebseite downloaden kann.
Mit "Upstream" meinst du nicht Debian Sid/unstable.
Ist das so richtig?

Ja genau, "Upstream" sind Projekte oder Unterprojekte wie LibreOffice, Firefox, GNOME, GTK, glib, X.org, Qt, GCC, glibc, Perl, CPython, PyPy , bash, ISC DHCP, Apache HTTP Server, exim, postfix, pulseaudio, VLC, GNU coreutils, curl, wget, mawk, gawk, Vim, GNU Emacs, XEmacs usw.
Distributionen werden manchmal auch aus "Downstream" bezeichnet.

Es besteht also die Möglichkeit, dass ein Debian Developer Code mit enthaltener Malware signiert und der ist dann dafür verantwortlich? Ist das so richtig?

Ja, vorsätzlich oder unabsichtlich.

Ebenso wird nie jemand davon etwas erfahren, wenn niemand den signierten Code überprüft bzw. einem Code Audit überprüft.

Ein Anwender könnte ungewolltes Verhalten der Anwendung beobachten, z.B. unauthorisierte Zugriffe o. Zugriffsversuche auf Ressourcen (URIs, Dateien, Deskriptoren, Interrupte, Sockets, Geräte etc.). Meistens ist es dann aber schon zu spät.
Es hilft, Software zunächst in einer abgesicherten Umgebung zu analysieren, z.B. mit chroot, strace etc. Der Quelltext ist hierfür nicht unbedingt nötig.
So funktioniert es im Prinzip auch für closed-source Anwendungen.

Gibt es wenigstens einen Codevergleich des Codes von Upstream also der Projektwebseite und dem, welcher der DD dann signiert und nach SID/unstable hochlädt?

Ja klar! Lade und entpacke das Quellpaket und den Quelltext von "upstream" und verwende diff(1) und patch geschickt. Laut Paketrichtlinien befnden sich bei Debian alle Patches/Differenzen zu "upstream" im Unterordner "debian/patches" des Quellpakets.

Dürfen DD Pseudonyme haben oder müssen sie immer ihren realen Namen angeben und falls letzteres zutrifft, wie wird das überprüft dass die Angaben auch wirklich stimmen?

IMHO: Soweit mir bekannt, nein. Man wird nur DD wenn DDs deinem DD-Schlüssel für die Signatur ihr Vertrauen aussprechen. Das geschieht momentan technisch via PGP. Dabei muss zwangsläufig auch die Identität verifiziert werden, was bisher nur persönlich auf Entwicklertreffen passiert. Man muss also zwangsläufig das Vertrauen der bestehenden DDs haben.

Die beste Möglichkeit die Identität/Authentizität zu fälschen, wäre vermutlich an den privaten Schlüssel eines DDs zu gelangen. Allerdings würde dieser sehr schnell erkennen, dass sein Schlüssel kompromittiert wurde, falls damit tatsächlich Schabernack betrieben würde. In dem Fall kann er und den Schlüssel unwiderruflich zurückziehen (PGP). All diese "unerwünschten"/"mutwilligen" Änderungen können andere DDs im Nachhinein via Versionsverwaltung rückgängig machen.
Es ist zu erwarten, dass die Dauer bis so etwas auffällt, deutlich kürzer als ein Freeze von testing bis zum darauf folgenden stable-Release ist.

Ich könnte mir gut vorstellen, das Geheimdienste Entwickler stellen, die sich dann als DD bewerben und einschleusen um dort dann Code zu platzieren, der für sie die Systeme öffnet.

Korrekt. Meist passiert das allerdings eher direkt bei "upstream" oder schon viel früher auf viel subtilere Art und Weise. Siehe auch den Verweis auf einen Vortrag von Poul-Henning Kamp zu von Snowden enthüllten NSA-Operation ORCHESTRA in meinem Kommentar unten.

Debian verwendet hier mWn die "best practices" im Vergleich zu vielen anderen OSS-Projekten, und ist somit i.A. nicht das schwächste Glied der Kette.

Gab es schon einmal den Versuch von Dritten, allen Code in Debian einem Code Audit zu unterziehen?

Alle "upstream"-Entwickler teilen sich die Aufgabe, oder? :D
Spaß beiseite: Ein Formaler Audit aller ~100Mio. Quelltextzeilen Debians wären mir nicht bekannt. Mir dünkt, als gab es einmal (vorher abgesprochene) Massenmeldungen von Fehlerberichten die durch statische Analysewerkzeuge entdeckt wurden. Finde dazu aber gerade nichts.