release: 0.3.0 — remote_cache_trees by tree kind

[SpencerC]

What & why

Releases 0.3.0: the remote_cache_trees split from
feature/reproducible-prepare-deps, one correctness fix found reviewing it, and
the changelog cut.

1. feat(flutter)!: split remote_cache_trees by tree kind (unchanged work)

//flutter:remote_cache_trees becomes a string flag — none (default),
workspaces, all — because the assembled pub cache and the prepared/overlay
workspaces have different economics. PrepareFlutterAppWorkspace gains the
execution posture every other tree-producing action already had, and the
dependency-preparation log drops its wall-clock timestamp.

Only the commit subject changed: the original was not a Conventional Commit,
so Commitizen would reject it and ccv would derive no version from it at all.

2. fix(flutter): classify a prepare action by the trees it declares (new)

The split landed with FlutterPrepareDeps still on the default
TREE_WORKSPACE, but that action declares its own pub cache tree whenever
it is not handed a preassembled one:

prepare_outputs = [pub_get_output, pub_deps, dart_tool_dir, prepared_workspace]
if preassembled_cache != None:
    prepare_inputs = prepare_inputs + [preassembled_cache]
else:
    prepare_outputs = prepare_outputs + [pub_cache_dir]   # <- multi-GB when assembling

An action carries one posture for all of its outputs, so
--//flutter:remote_cache_trees=workspaces would have lifted no-remote-cache
off an action uploading a pub cache — exactly the trade the flag was split apart
to avoid. Worst case is the assemble + pub_package combination, where that
tree is the full merge.

prepare_deps_tree_kind now takes the more restrictive kind whenever a pub
cache is among the declared outputs, and the call site derives its argument from
the prepare_outputs list itself rather than re-deriving the branch condition,
so classification cannot drift from the outputs.

Also repairs the three remote_cache_trees docstrings, which kept a dangling
and False from the boolean they used to describe, and documents the
per-action rule in docs/hermeticity.md and the changelog.

An analysis test would be the natural home for the invariant, but Starlark's
Action exposes no execution requirements — ["args", "argv", "content", "env", "inputs", "mnemonic", "outputs", "substitutions"] — so it is pinned as a unit
test on the pure helper instead.

3. chore(release): cut 0.3.0

A breaking flag change is a minor bump while the module is pre-1.0.

⚠️ Do not release this by dispatching Tag a Release

ccv has no 0.x special case —
ccv.go matches
^(fix|feat)(\(.+\))?!: |BREAKING CHANGE: straight to IncMajor(). A dispatch
over this branch would tag v1.0.0, and tag.yaml's own
new-tag-version-type != 'major' guard would then skip the release job,
leaving a major tag with no artifacts behind it.

After merge, push the tag by hand — release.yml triggers on v*.*.*:

git tag v0.3.0 && git push origin v0.3.0

A comment in tag.yaml now records this so the next person does not find out
the hard way.

Checklist

• bazel test //flutter/tests:all_tests //docs:update_tests passes — 16/16
• cd e2e/smoke && bazel test //:integration_tests passes — 21/21
• Ran bazel run //docs:update if any rule/macro API changed — no public API
  change; //docs:update_tests confirms the goldens are current
• pre-commit run --all-files (buildifier + prettier) is clean
• Updated docs/README for user-facing changes — docs/hermeticity.md +
  CHANGELOG.md

🤖 Generated with Claude Code