Photo reply shares its wire action with the ack; success flag is misused to tell them apart

Follow-up to #232, which fixed the same shape for video (StopRecordingFinished).

The problem

TakePicAck and TakePicResp are both encoded with CommandAction.TakePicture. The decoder tells them apart by sniffing the payload:

case .takepicture:
    if resp.success && !resp.hasMediaData && nsError == nil {
        return TakePicAck(sender: nil)
    } else {
        return TakePicResp(sender: nil, pic: picData, error: nsError)
    }

With "Send Media to Remote" off, a successful result has no bytes and no error, which would look like the ack. To keep them apart the encoder writes a successful-but-unsent result as a failure:

success: error == nil && pic != nil   // RemoteCmdFlatBuffers.swift, TakePicResp.toFlatBuffer

Nothing is wrong with the photo; the flag lies purely to route the decoder. It works today, but the schema does not say what it means, and any future field on the photo reply has to keep this trick alive.

The fix (same recipe as video)

• Add TakePictureFinished to CommandAction in FlatBufferSchemas.fbs; regenerate with flatc.
• TakePicAck stays on .takepicture; TakePicResp encodes on .takepicturefinished with success: error == nil and the still's bytes when present.
• Decoder: .takepicture → ack, .takepicturefinished → result. No payload sniffing.
• Rename media_data to photo_data while at it: after #232 the field is only ever a still, and the name should say so.
• Simplify TakePicResp to one initializer (sender:pic:error: with defaults).
• Serialization tests: a successful result with no photo must decode as a result, not the ack, and the raw response must read success == true.

Scope notes

• Breaking wire change; both devices update. No compat shims.
• Photos legitimately ride inline in the reply (a still is a few MB), so this is a naming/clarity fix, not a memory one.
• The multicam director's photo collection decodes through the same path; its tests cover it.

Start with FlatBufferSchemas.fbs and the generated handling in RemoteCmdFlatBuffers.swift, then inspect the serialization tests and the multicam director tests mentioned in the issue. Verify that separate take-picture actions decode acknowledgements and results correctly, that photo_data is used consistently, and that a successful result without photo bytes remains a result with success == true.