Fix X11 input barrier when dock is hidden; increase dwell strip height

[vireonxi-om]

Fixes #317.

Symptom

With autohide enabled on X11, clicks in the bottom band of the screen (roughly the dock's height, full monitor width) never reach the application window underneath while the dock is hidden.

Root cause

The dock container is a chrome actor sized to the full monitor width/dock height, and keeps that size when the dock slides out — only the inner dash is translated off-screen and struts is hidden. Because the container is registered via Main.layoutManager.addChrome() with affectsInputRegion left at its default (true), its whole rect stays in the shell's X11 stage input region permanently. Clicks landing there are delivered to the shell stage instead of the window below. Wayland ignores the stage input region, so this only reproduces on X11.

Changes

1. Register the dock container with affectsInputRegion: false (the line was already present, commented out). Input for the visible dock is already carried by the struts actor (input-region tracked, hidden together with the dock), and the dwell strip still reveals the dock at the screen edge.
2. Bump the dwell reveal strip from 2px to 4px so the edge hover target is a bit easier to hit reliably.

Verification

On Ubuntu 24.04, GNOME Shell 46, X11, extension v92, dock at bottom, autohide + dodge enabled:

• Before: synthetic clicks (xdotool/xev) into a window placed in the bottom zone were swallowed.
• After: the same clicks arrive correctly (ButtonPress/ButtonRelease land on the window underneath). Dock still reveals via the edge dwell strip, icons stay clickable, hide/dodge behavior unchanged.

Note: this addresses the same root cause as #342 (arrived at independently and verified on my own machine before noticing that PR); this one additionally includes the dwell-height bump. Happy to close in favor of #342 if maintainer prefers a single fix — just flagging both exist.

[benny-png]

Heads up on one edge case, since I hit this same bug and landed on your diagnosis independently — the container/affectsInputRegion analysis here matches what I found.

The one gap: this fix relies on struts carrying the input region for the visible dock, which is true when autohide is enabled, because animator.js narrows it there:

if (dock.extension.autohide_dash) {
  dock.struts.x = dock._background.x + dock._monitor.x;
  dock.struts.width = dock._background.width;
}

With autohide disabled that branch never runs, struts.width stays at dock.width (full monitor width), and addToChrome() still registers it with affectsInputRegion: true. So for that configuration the dead band survives this change — the container stops covering it and struts keeps covering it.

I've opened #356 with the struts half plus trackChrome() on the visible actors, verified in both autohide states. It's written against main rather than on top of this, so it stands alone — but I'd rather not step on your work, and I'm happy to close mine in favour of you extending this one if you'd prefer. Entirely up to you and the maintainer.