[Phlabry]

Closes #239. Updates #195 with the port, which that issue can keep tracking for the import procedure.

#239 was written when nobody knew the port and asked for a placeholder that clearly was not a value to copy. We now have the real one, so this does the better version of that: carry the confirmed value with its provenance, instead of a number three files happened to agree on.

Where 5050 came from

Read off the lab machine's iMotions install, Global Settings > API > Event Receiving, with Enable event reception and Use TCP both ticked. The same panel lists our event source as Id: PilotDataSync, version 1, Positional Flight Data, which matches what the relay's generated iMotions.xml defines and what it puts on the wire.

It is a setting rather than a product default, so the README says to check it on whichever machine you are using instead of trusting the placeholder.

Changes

• relay/src/view.rs: placeholder is 127.0.0.1:5050, with a comment recording where the value came from.
• relay/src/state.rs: the validation message matches.
• src/server/src/main.rs: the mock keeps 9999, now labelled as its own local testing port so running it is never mistaken for talking to iMotions. That was Relay's 127.0.0.1:9999 placeholder reads like a real iMotions port #239's suggestion and it still holds.
• README.md: a short section on reading the port off the API tab, what the event source should look like, and which three ports on that same tab are not ours. The "nothing confirms it is iMotions' real port" warning is replaced.

Still open

How iMotions.xml is imported is still undocumented. It was already registered on the lab machine and nobody on the team performed the import, so #195 stays open for that half.

Untestable here: the relay has still never been pointed at a real iMotions instance. This changes a default and documentation only, and the relay has no default address, so nothing connects anywhere on its own.

[jmacd867]

Thanks for tracking down the port. Documenting where to read it (Global Settings > API > Event Receiving) in the README is exactly what #195 needed.

A few things before this closes #239:

1. The placeholder is still a value people will copy. The placeholder (DEFAULT_TCP_PLACEHOLDER) and the validation error both read 127.0.0.1:5050. #239 asked for something "clearly not a value to copy", and that's what happened with 9999. 127.0.0.1 also means the relay's own machine, but in the lab iMotions runs on a separate computer. Could the placeholder, the error message and the README examples (README.md:105-108) all use something like <iMotions IP>:5050?

2. The mock server still prints a bare 9999. The comment is updated, but #239 asked for the output to say it too. The startup line (Server listening on ...) and the usage line ((default 9999)) could say it's a local testing port, not iMotions'.

3. Smaller, take or leave:

• The error message could build its text from the placeholder constant, so the next port change is one edit instead of two.
• The name DEFAULT_TCP_PLACEHOLDER contradicts its own comment ("a setting rather than a fixed default"). Maybe IMOTIONS_ADDR_HINT?
• "9999 used to sit here..." in view.rs is history and fits better in the commit message.
• docs/client_meeting_notes.md (lines 61 and 68) still lists the port as open. That's fine as a meeting record, but a one-line pointer to the #195 comment would stop people from rereading it as unresolved.

cargo test in relay passes (8/8) and the mock server builds. I can't check 5050 end to end without the lab machine.