Esc Crop Stress: restore Help, hide consultant SPACE chip

[WizardlyPayload]

Summary

• Restore Esc Crop Stress footer Help (opens Crop Stress help dialog).
• Hide the on-page SPACE Crop consultant activate chip.
• Keep Agronomist / Pivot / field table as-is.
• Nine-door sync of the Crop Stress Help footer branch on Esc door carriers.

Test plan

• Full client restart
• Esc Realistic Farming to Crop Stress
• Footer shows Back + Help; Help opens Crop Stress help dialog
• No SPACE Crop consultant chip
• Agronomist and Pivot still visible

[sasha-rf]

Approved

This is the tail of the Esc door sync, not a new change. Reviewed as such.

What it does

RfEscModules:registerModule was dropping onOpenHelp on the floor, so the Crop Stress guest's help handler never survived registration. That is the same trap the file already carries two comments about, for onOpenConsultant and onPivotRemote. Forwarding it is the fix.

On top of that, btnHelpCs goes back on the CS footer at MENU_EXTRA_1, so the footer reads Back + Help instead of Back alone. onClickHelpCs resolves the active panel's onOpenHelp first and falls back to CsRfPdaGuest.onOpenHelp, both under pcall, both type checked. It correctly does not reuse Soil's btnHelp, which would open the wrong dialog.

The dead consultant chip stays constructed but is never assigned to menuButtonInfo. That is the right call over deleting it: stale bindings still resolve, and the player cannot press a no-op.

Verification

I did not review this as three changes, because it is not three changes. I pulled the head blobs from the fork for all three PRs and diffed them against the copy already merged and shipping in FS25_WorkerCosts:

• src/gui/RfPdaMenuPage.lua: 0 differing lines
• src/gui/RfEscModules.lua: 0 differing lines

The three PRs are also byte identical to each other apart from the modDesc header. This exact code is already live in IncomeMod, NPCFavor, TaxMod and WorkerCosts, and in SoilFertilizer via #827. Four of those carriers hash identically to each other on disk.

Version bump matches the current development head in each repo. Merge state CLEAN, no UTF-16 BOM in the head tree.

One finding, non blocking

tr("cs_pda_btn_help", "Help") will never resolve the key in a carrier mod. The resolution chain in tr() is MOD_NAME, then FS25_SoilFertilizer, then FS25_SoilFertilizer_Refined, then global g_i18n. cs_pda_btn_help ships only in FS25_SeasonalCropStress translations, and that environment is never consulted. Global g_i18n:getText with no customEnv reads only the base game table (I18N.lua:175), returns the Missing '...' string, and tr's own guard rejects it.

So the button renders the hardcoded English "Help" in all 26 languages. Cosmetic only, no crash, and the English fallback is presumably exactly why it is there.

Flagging it because it is easy to assume the key works. It is not a regression from these PRs: the four already merged carriers behave the same way today, so this is a gap in the whole rollout rather than anything wrong here. It wants a follow up that either ships the key per carrier or adds SCS to the tr() chain, and it should not hold these three.

Not verified by me

The in game pass in the test plan. Code identity with five shipping carriers is strong evidence, but it is not the same thing as opening the door and pressing the button.

[sasha-rf]

@TheCodingDad-TisonK verified and approved, ready to merge.