PBKDF security if all but one keys are exposed
In case 3, one must consider that the knowledge of $salt_2$ and $k_2$ (or/and other ones) allows to test a guess of $pwd$ with about $c$ evaluations of $H$. The "brute force" attack becomes doing this with a dictionary of passwords with the most common first. Password crackers using GPUs or ASICs reach astonishingly high hash rates, and for $c$ in the thousands, if a password is memorable, it is best to consider that it is not safe form a well-funded attacker. That's why state of the art is memory-intensive password hashes, e.g. Scrypt, Argon2, Balloon, which make a large difference.

In a multi-target attack (where several $pwd$ each with their associated $salt_2$ and $k_2$ can be attacked, and finding any is a success for the attacker), the attacker should try the most likely $pwd$s on all available instances of the problem s/he's trying to attack before moving to less likely ones. Practical chances of success grow very fast with the number of different users having chosen $pwd$ !

I'm unaware of another weakness of PBKDF1 / $H^{(c)}(pwd\mathbin\|salt)$ that would be exploitable in the situation, and leak any info about $k_1$ without a successful guess of the full $pwd$ (if we leave a aside implementation issues like side-channels).

Note: in theory, the many iterated hashes of PBKDF1 reduce the possible values for the outcome as $c$ increases (see this). A wild guess of $k_1$ with a sizably better than random chance to match is plausible. However, for any hash at least as wide and remotely secure in the ROM as SHA-1, the probability of success remains so low that this is never a practical issue; and truncating the final result of PBKDF1 (which dramatically increases the probability of success of a wild guess) reduces to almost nothing the advantage that could be obtained by exploiting said effect of many iterations.

PBKDF1 successor's PBKDF2 fixes the above theoretical weakness, and allows producing large output, which can come handy. Neither comes with a security argument that it is a strong PRF (as HMAC does). However the main reason to discourage using PBKDF1 or PBKDF2 is that they are among what gives the least resistance to brute-force password crackers for a given level of effort by the legitimate user (number of iterations $c$).