As pointed in comment
- "encrypt" with sender's private key is improper terminology; the proper term is sign.
- it's assumed $n_r>n_s$ so that $c_1<n_r$, which is necessary to get $\widetilde{c_1}=c_1$. Thus the technique won't "work" with 100% reliability in both directions.
Also, the issue of padding is ignored. And more broadly the goal is not stated.
Issue 2 can be solved in a number of ways
- The best is to use separate keys for signature and encryption, with a maximum $n$ for the first applied (signature in the question) lower than the minimum for the second. That also abides to the time-proven principle: one usage, one key. It also avoids ending up with $c_2=m$ when the sender is the receiver, something an adversary might induce.
- Another option is to force all $n$ to share the same bit size and many high order bits (say 512, which become a fixed public arbitrary constant). That insures $c_1<n_r$ with overwhelming probability. It does not solve the send-to-self issue.
- Yet another is to require all $n$ to have the same bit size, restrict to (say) even $m$, and use $c_1\gets \min\bigl((m^{d_s}\bmod n_s),(-m^{d_s}\bmod n_s)\bigr)$. On decryption, we'll have either $m=\widetilde{c_2}$ or $m=n-\widetilde{c_2}$, and the parity of $m$ allows to determine which. It does not solve the send-to-self issue.