A `params` block makes pipe-form operators undefined in the entry workflow

Problem

In a script without nextflow.enable.types, declaring a params { } block causes the entry
workflow to lose the DSL1 operators (view, map, filter, …) from its scope. Any operator called
via the pipe form then fails to compile with "x is not defined". Named workflows in the same file
are unaffected, and so is the dotted call form.

The script does not run — this is not limited to nextflow lint.

Minimal reproducible example

params {
    greeting: String = 'hello'
}

workflow {
    channel.of(1, 2) | view()
}

Observed:

Error mre.nf:6:24: `view` is not defined
│   6 |     channel.of(1, 2) | view()
╰     |                        ^^^^

ERROR ~ Script compilation failed

Expected: the pipeline runs and prints 1 and 2.

Deleting the params block — the only change — makes it run:

workflow {
    channel.of(1, 2) | view()
}

1
2

An empty params { } block triggers it too, so it is the block's presence rather than its
contents.

Scope

One file showing what is and is not affected:

params {
    greeting = 'hello'
}

workflow SUB {
    take:
    ch

    main:
    ch | view()        // OK — named workflow
}

workflow {
    def a = channel.of(1, 2)
    a.view()           // OK — dotted form
    a | view()         // Error: `view` is not defined
}

The params block is otherwise fully functional — the same script with the dotted form runs and
reads the param:

params {
    greeting = 'hello'
}

workflow {
    channel.of(1, 2).view()
    println "greeting is ${params.greeting}"
}

greeting is hello
1
2

Summary

	no params block	params block
untyped (no flag)	a | view() works	a | view() fails
nextflow.enable.types = true	fails	fails

Per https://docs.seqera.io/nextflow/workflow-typed I don't think there should be a problem with using the params block without typing:

Set nextflow.enable.types = true in every script that uses typed workflows. The params block
and output block can be used without this feature flag.

And per https://docs.seqera.io/nextflow/workflow#special-operators--and- I don't think | is disallowed either?:

These operators are not supported when static typing is enabled

Environment

• Nextflow 26.04.4
• Reproduced with both nextflow run and nextflow lint

Start by running the minimal example with nextflow run, then compare it with the version without the params block and the dotted-call variant. Trace how the entry workflow resolves pipe-form operators when a params block is present; done means the example compiles and runs, printing 1 and 2, without breaking the unaffected cases.