[Paddle FE] dropout: scale with a constant of the input element type

[siyiweigeHEW]

Details:

• dropout with dropout_implementation = downgrade_in_infer is converted to X * (1 - dropout_prob), but the scale constant was always created with ov::element::f32. A model whose input is not float32 therefore failed to convert at all:

Check 'element::Type::merge(result_et, node->get_input_element_type(0), node->get_input_element_type(1))' failed at src/core/src/op/util/elementwise_args.cpp:18:
While validating node 'opset1::Multiply Multiply_3 (opset1::Parameter x[0]:f64[2,2,3], opset1::Constant Constant_2[0]:f32[1]) -> (dynamic[...])' with friendly_name 'Multiply_3':
Arguments do not have the same element type (arg0 element type: f64, arg1 element type: f32).
   FrontEnd API failed with OpConversionFailure: Fail to convert dropout

• Paddle exports such a model and runs it: in inference a dropout with downgrade_in_infer is just a scale by (1 - p), so nothing in the exported graph depends on the input being f32. This is a front-end robustness gap, not a Paddle restriction.
• The fix builds the scale in f32 and ConvertLikes it to the input. ConvertLike is used rather than typing the constant with the input element type directly because the element type of the input is not necessarily resolved during conversion (the same reasoning as create_same_type_const_scalar() in atan2.cpp, which exists for exactly this case).

Reproducer

import numpy as np, paddle, openvino as ov

x = (np.arange(1, 13, dtype="float64").reshape(2, 2, 3) / 8.0)
fn = lambda xx: paddle.nn.functional.dropout(x=xx, p=0.5, training=False, mode="downscale_in_infer")

paddle.jit.save(paddle.jit.to_static(fn), "/tmp/m", [paddle.static.InputSpec(shape=list(x.shape), dtype="float64", name="x")])
ov.Core().read_model("/tmp/m.pdmodel")   # OpConversionFailure before this change, works after

Same failure with float16. Before the change: float64 and float16 both fail to convert on master and on 2026.1.0; float32 is unaffected.

Verification

Built the Paddle front-end from this branch and compared OpenVINO against Paddle's own execution of the exported model (paddle.static.load_inference_model), 3 dtypes x 2 dropout_implementation modes:

dtype	mode	before	after	max diff vs Paddle
float32	downscale_in_infer / upscale_in_train	OK	OK	0
float64	downscale_in_infer	OpConversionFailure	OK	0
float64	upscale_in_train	OK	OK	0
float16	downscale_in_infer	OpConversionFailure	OK	0 (reference: x * (1 - p), Paddle CPU has no float16 dropout kernel)
float16	upscale_in_train	OK	OK	0

• float32 behaviour is unchanged (upscale_in_train is a pass-through and is not touched).
• No fuzzy test model is added on purpose: FrontEndFuzzyOpTest (src/frontends/tests/frontend/shared/src/op_fuzzy.cpp) only loads f32/i32/i64/boolean inputs and outputs and throws for any other dtype, so the non-f32 case this PR fixes cannot be expressed in op_fuzzy.cpp.

Tickets:

• N/A

AI Assistance:

• AI assistance used: yes
• If yes, summarize how AI was used and what human validation was performed (build/tests/manual checks).
  AI assisted with the root-cause analysis and the implementation. Human validation performed: local build of
  openvino_paddle_frontend from this branch, the reproducer above run before/after the change against Paddle
  2.6.2 for 6 dtype/mode combinations, and a check that the float32 path is bit-identical to Paddle.