I love it!
But it's missing one thing from the proposal, the darkening across the tracks as can be seen here. I hope this could be added as well.

Is there a way to proportionally adjust the keys too (maybe while holding a key like Ctrl or Shift), essentially making the animation slower or faster?

No. What you're asking for is key scaling, this PR is just for resizing the animation length.

I love it!
But it's missing one thing from the proposal, the darkening across the tracks as can be seen here. I hope this could be added as well.

Hoo, boy. Just addressed that part of the proposal, and kinda fell on a rabbit hole of fixing drawing bugs, which now makes this PR a bugfix as well.

The video in the OP has been updated.

Does it support snapping?

It snaps to the animation step by default, with the option of more granular movement by holding Shift. Basically how it works with keys/markers.

What if the animation cursor is at the end of the animation? Would the code prioritise moving the cursor or the animation end?

The animation end is prioritized. As the cursor can be moved by clicking anywhere below it.

I created a new animation and it crashed when I tried resizing:

CrashHandlerException: Program crashed
Engine version: Godot Engine v4.6.dev.custom_build (b7c5fcaf1ef716b13e4f229ab9f591a22badbe1b)
Dumping the backtrace. Please include this when reporting the bug on: https://github.com/godotengine/godot/issues
[0] AnimationTrackEdit::get_editor (C:\godot_source\editor\animation\animation_track_editor.h:532)
[1] AnimationTrackEdit::get_editor (C:\godot_source\editor\animation\animation_track_editor.h:532)
[2] AnimationTimelineEdit::gui_input (C:\godot_source\editor\animation\animation_track_editor.cpp:1981)
[3] Control::_call_gui_input (C:\godot_source\scene\gui\control.cpp:1867)
[4] Viewport::_gui_call_input (C:\godot_source\scene\main\viewport.cpp:1751)
[5] Viewport::_gui_input_event (C:\godot_source\scene\main\viewport.cpp:2169)
[6] Viewport::push_input (C:\godot_source\scene\main\viewport.cpp:3507)
[7] Window::_window_input (C:\godot_source\scene\main\window.cpp:1834)
[8] call_with_variant_args_helper<Window,Ref<InputEvent> const &,0> (C:\godot_source\core\variant\binder_common.h:223)
[9] call_with_variant_args<Window,Ref<InputEvent> const &> (C:\godot_source\core\variant\binder_common.h:337)
[10] CallableCustomMethodPointer<Window,void,Ref<InputEvent> const &>::call (C:\godot_source\core\object\callable_method_pointer.h:103)
[11] Callable::callp (C:\godot_source\core\variant\callable.cpp:57)
[12] Callable::call<Ref<InputEvent> > (C:\godot_source\core\variant\variant.h:938)
[13] DisplayServerWindows::_dispatch_input_event (C:\godot_source\platform\windows\display_server_windows.cpp:4459)
[14] DisplayServerWindows::_dispatch_input_events (C:\godot_source\platform\windows\display_server_windows.cpp:4429)
[15] Input::_parse_input_event_impl (C:\godot_source\core\input\input.cpp:979)
[16] Input::flush_buffered_events (C:\godot_source\core\input\input.cpp:1262)
[17] DisplayServerWindows::process_events (C:\godot_source\platform\windows\display_server_windows.cpp:3820)
[18] OS_Windows::run (C:\godot_source\platform\windows\os_windows.cpp:2331)
[19] widechar_main (C:\godot_source\platform\windows\godot_windows.cpp:96)
[20] _main (C:\godot_source\platform\windows\godot_windows.cpp:122)
[21] main (C:\godot_source\platform\windows\godot_windows.cpp:136)
[22] WinMain (C:\godot_source\platform\windows\godot_windows.cpp:150)
[23] __scrt_common_main_seh (D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288)
[24] ShimMainCRTStartup (C:\godot_source\platform\windows\cpu_feature_validation.c:74)
[25] <couldn't map PC to fn name>
-- END OF C++ BACKTRACE --

@KoBeWi Fixed.

@KoBeWi Fixed that, and also on the timeline cursor and track list resizing as well.

Right-clicking to cancel still opens context menu. I think it should not.

EDIT:
Also, shouldn't it undo the change?

Made right-clicking undo the resize operation. Also fixed the cursor and track name dragging still happening when you open the menu.

We looked at some of this in the meeting and we want to point out that PR #105151 also exists and implements a bit more of the visuals and maybe a little closer to what we want.

I think it's a little early to say which approach is best since neither change appears to be complete. A video would be helpful too.
Some of the comments we had there might be relevant to this change too:
#105151 (comment)

I don't know why we were confused during the meeting but this PR makes sense. This does not conflict with another PR so I am retracting my comment. I apologize for the confusion.

These do not implement the same thing and can co-exist. Or did you link the wrong PR?
This implements dragging to change the animation length of the timeline without modifying the keyframes, it only modifies this property:

while #105151 implements scaling of the time between keyframes and does not modify the animation length.

I retract my last comment. We were reviewing a bunch of animation PRs and people in the meeting were either looking at the wrong PR or just got confused. Please ignore our earlier comment and I am making a note to look at this again during the next public animation meeting in a week on next Friday. (You're welcome to join too).

We discussed this in an animation meeting, and it looks good. we just need to review the code and then it should be good.

Also it would help if you can rebase and fix conflicts. Never mind it seems fixed after I refreshed

I can offer more interesting sliders from my suggestions - godotengine/godot-proposals#13583 (comment)
At the moment, the sliders are too primitive, these look like what we are used to seeing in other timelines.

I can offer more interesting sliders from my suggestions - godotengine/godot-proposals#13583 (comment)

Currently, Animation cannot handle the keys which are on negative time reliably (and this PR doesn't handle start of the animation), so designs that appear to allow manipulation of both ends are not ideal. I believe it is important to clearly indicate that only the animation end (not start) can be manipulated.

Thanks!