fix(api): include name and arguments in operation hash

[wowi42]

Fixes #1370, implementing the approach from this analysis.

Problem

solve_operation_consistency built the operation hash purely from position (stack lines in CLI mode, per-host index in API mode, plus host.loop_position). Names and arguments were never hashed, and the duplicate-resolution loop only checked the current host's op_hash_order. As a result, different operations at the same position (eg calls in a plain for loop with per-host data) collapsed into a single hash:

• ensure_shared_op_meta unioned their names into one set, so the "Detected changes" output showed a nondeterministic name and merged host counts
• if the colliding operations differed on _parallel, _run_once or _serial, the deploy died with OperationValueError: Cannot have different values for ...
• _run_once semantics broke, running the merged op on the first host only

Fix

Hash the operation names and arguments (normalized via _get_arg_value, so functions and StringIO stay deterministic) alongside the position. Different operations at the same position now get distinct hashes, while identical operations across hosts still share one hash, keeping cross-host dedup and _run_once/_serial/_parallel grouping intact. The same-host duplicate suffix behavior (hash-0, hash-0-1, ...) is unchanged.

Tests

• test_op_per_host_data_no_hash_collision - per-host named ops get distinct hashes; identical ops still share one
• test_op_per_host_args_no_name_no_hash_collision - same op/position with per-host args but no explicit name=
• test_op_per_host_data_different_execution_kwargs - no false OperationValueError for distinct ops with different _parallel
• test_cli_op_loop_per_host_data_no_hash_collision - exact issue repro in CLI mode (plain loop, same line)
• test_cli_op_loop_identical_ops_dedupe - identical same-line loop calls still dedupe via hash suffixes

All collision tests fail on the old code; the dedup test passes on both.