No estás entendiendo...
Primero, no digo que no puedas tenerlos. Digo que no es necesario declarar a ambos como PK, porque eso puede llevar a admitir inserciones erróneas.
Supongamos que tienes dos clientes ClienteA y Cliente B, tal que el ClienteA tenga los codigos 1 y 3, y el ClienteB los codigos 10 y 14.
En tu tabla, tal y como lo has planteado, este conjunto de claves sería válido:
Cita: (1, 3)
(1, 14)
(10, 3)
(10, 14)
Desde el punto de vista de las restricciones de PK, esos cuatro parers de claves son válidos, pero son datos erróneos desde el punto de vista funcional.
Para evitar que se introduzcan datos así deberías controlarlo en la aplicación, ya que la base no podrá.
¿Se entiende ahora?
Ahora bien, lo que estás planteando es el uso de lo que se denomina
clave alternativa, o
clave candidata, y eso no se hace de esa forma. Se hace declarando el segundo campo, la clave secundaria, como UNIQUE.
Así de simple.
De todos modos, ni siquiera necesitas ese campo allí para implementar esto que dices:
Cita: los codigos de clientes son distintos para las dos aplicacione
Bastaría con una tabla adicional que relacione la PK de la tabla de clientes con un código alternativo único. No es raro y es sencillo de implementar, y no te traerá complicaciones con el resto de la base. Simplemente usas esa tabla para obtener el código correcpondiente a la aplicación secundaria.
¿Se comprende la idea?
Incluso más: MySQL
admite que un campo UNIQUE ser use como FK en otra tabla, por lo que si quiesieras usar el código secundario en alguna restricción, no tendrías problemas.