build: initialize hk git hook manager with biome format

[tylerbutler]

Summary

• Adds hk.pkl configuration to initialize the hk git hook manager
• Configures a biome-format pre-commit hook that auto-formats staged files using biome format --write and re-stages the results
• Extends the built-in Builtins.biome step with format-only commands (no linting)

[Copilot]

Pull request overview

This PR introduces an hk.pkl configuration at the repo root to adopt the hk git hook manager, with a pre-commit Biome formatting step intended to auto-format staged files and re-stage the results.

Changes:

• Added hk.pkl extending hk’s built-in configuration and importing hk builtins.
• Defined a biome-format step and wired it into pre-commit, plus fix and check hooks.

---

You can also share your feedback on Copilot code review. Take the survey.

[github-actions]

🔗 No broken links found! ✅

Your attention to detail is admirable.

linkcheck output

> [email protected] ci:check-links /home/runner/work/FluidFramework/FluidFramework/docs
> start-server-and-test "npm run serve -- --no-open" 3000 check-links

1: starting server using command "npm run serve -- --no-open"
and when url "[ 'http://127.0.0.1:3000' ]" is responding with HTTP status code 200
running tests using command "npm run check-links"


> [email protected] serve
> docusaurus serve --no-open

[SUCCESS] Serving "build" directory at: http://localhost:3000/

> [email protected] check-links
> linkcheck http://localhost:3000 --skip-file skipped-urls.txt

Crawling...

Stats:
  257792 links
    1822 destination URLs
    2063 URLs ignored
       0 warnings
       0 errors

[alexvy86]

I'm tempted to approve this blindly just because HK has a sea-shanty 😆 .

I feel a bit conflicted about the additional toolset required for this (more things that people (might) need to know to work on the repo), but being opt-in mitigates that somewhat. Should we consider this an "experimental" thing in the repo for now, and eventually graduate it to a formal "this is a tool we're fully committed to leveraging/supporting" (even if it's still opt-in)? I think that's my main piece of feedback, I'd personally would go with docs (and comments in the pk1 file) that suggest that vs "in this repo we use X".