chore(release): bump version to v0.1.1

[yingdi-shan]

Summary

• centralize the product version under workspace.package and bump it to 0.1.1
• make the AgentENV server and aenv CLI inherit the shared version
• reject release tags that do not match either shipped package version

Verification

• cargo fmt --all --check
• cargo check -p agentenv -p aenv --locked
• cargo run --quiet -p aenv -- --version outputs aenv 0.1.1
• release tag/version validation script passes for v0.1.1
• modified GitHub Actions workflow parses as valid YAML

After this PR merges, v0.1.1 can be tagged on the merge commit to start the existing release workflow.

[github-actions]

🔍 OpenCodeReview found 3 issue(s) in this PR.

• ✅ Successfully posted inline: 3 comment(s)

[github-actions]

[security · medium]
This new job does not declare token permissions, so its GITHUB_TOKEN access depends on the repository's potentially broader default. The validation only needs to check out the repository; explicitly grant read-only contents access at the job level.

Suggestion:

Suggested change

	validate-version:
	name: Validate release version
	runs-on: ubuntu-24.04
	validate-version:
	name: Validate release version
	runs-on: ubuntu-24.04
	permissions:
	contents: read

[guozy18]

Adding explicit read-only permissions to the validate-version job would be a reasonable least-privilege improvement:

permissions:
contents: read

I don’t consider this blocking, though.

[github-actions]

[other · low]
The new validation job has no timeout, so a stalled toolchain installation or cargo metadata invocation can consume a runner indefinitely and block all dependent release jobs. Add an appropriate timeout-minutes value.

Suggestion:

Suggested change

	name: Validate release version
	runs-on: ubuntu-24.04
	steps:
	name: Validate release version
	runs-on: ubuntu-24.04
	timeout-minutes: 10
	steps:

[github-actions]

[security · high]
dtolnay/rust-toolchain is a third-party action and stable is a mutable ref. If that ref is moved or compromised, release-tag runs can execute changed code. Pin this action to a reviewed full commit SHA (a trailing comment can document the corresponding version/ref).

[LSX-s-Software]

Can you merge #87 before releasing v0.1.1?

[guozy18]

LGTM.

[guozy18]

Adding explicit read-only permissions to the validate-version job would be a reasonable least-privilege improvement:

permissions:
contents: read

I don’t consider this blocking, though.

[yingdi-shan]

PRs #87, #86, #92 are large changes — not in terms of lines of code, but because they introduce new features and new architecture. They shouldn't go into a minor release.

That said, I think we should start preparing for a major version release as soon as possible.