Fixed wrong link for webui build instructions in README

[tempodat]

Previous link was just the diff of some random commit about date handling? I'm assuming it was just a mistaken paste. Changed it to a more appropriate link.

[2e3s]

No, the link was a specific commit which has been tested on. The main branch may have a broken code at any given moment. CI build also refers a specific commit rather than main branch (missed the mismatch with docs). It all should be updated probably to https://github.com/ActivityWatch/aw-webui/tree/464405d33d1b29d86b9e7c4a0bee708951f24b46 which is indirectly referred by the latest release https://github.com/ActivityWatch/activitywatch/tree/v0.14.0b3

[tempodat]

Oh, well should i edit the PR to change it to that link?

In truth the relevant section is the #building section, which just includes two commands, npm ci && npm run build. I only opened the commit because it confused me for a while while trying to build from source. I can change the link to https://github.com/ActivityWatch/aw-webui/tree/464405d33d1b29d86b9e7c4a0bee708951f24b46#building, or I can just copy those commands instead of the link. What do you think?

EDIT: Wait, if the build requires a specific version of webui anyway, then why not add it as a git submodule? Since you don't have any other submodules, the build instructions would become as simple as running git submodule update --init --recursive (and following its build instructions) if you want webui and not doing that if you don't. You could even make the default value of AW_WEBUI_DIR be the relative location of the submodule, simplifying the build further.

[2e3s]

should i edit the PR to change it to that link?

It would be nice if you do, yes, https://github.com/ActivityWatch/aw-webui/tree/464405d33d1b29d86b9e7c4a0bee708951f24b46#building would be appropriate.
Also here if possible https://github.com/2e3s/awatcher/blob/main/.github/workflows/release.yml#L37

if the build requires a specific version of webui anyway, then why not add it as a git submodule?

That's a reasonable idea, technically, and I thought about it initially. This concerns only the bundle, I wasn't sure how to position the app, submodules aren't very widespread, and if I'm not going to split into a separate repo, and made the more conservative choice. Possibly, I might review that decision.