'Personal' namespaces in calmhub

## Feature Proposal

### Target Project:
CalmHub

### Description of Feature:
Continuing the theme of scratch work needing better support, as raised in #3023, add the notion of a user-specific namespace that implicitly exists for every user.

User-specific namespaces:
- do not exist until a user pushes something to them
- are conventionally named based on the user identity that first created them i.e. `osbornew-scratch` for user `osbornew`
- when created, grant `ADMIN` to the user creating them, and explicitly remove READ from other users
- build a simple link sharing feature to allow sharing documents quickly in the UI
- if the user wants other users to view/work on the NS they can then grant other users access via the entitlements panel
- Users determine their personal namespace name via the CalmHub UI, which will show it on the front page

### User Stories:
As a user, I want a quick namespace to do scratch work in without having to ask an admin to make a namespace for me.

As a user, I want to quickly share a link to a document with other users without having to explicitly grant them access.

### Current Limitations:
Namespaces need to be explicitly created by a GLOBAL_ADMIN today.

### Proposed Implementation:
- When validating that a namespace exists as part of a create/update operation, don't immediately fail if namespace does not exist
- Instead, fall through to logic that checks the namespace name; if it's `$USER-scratch`, create the namespace and then proceed with original operation
- Initial state for namespace is ADMIN for creating user, default READ removed for other users
- CalmHub front page has a button to jump to the user's personal namespace, which also shows the user the value of that NS so they can push to it via the CLI

Link sharing system:
When viewing a document in a namespace that does not grant READ to '*' i.e. is not default-readable:
- Show a 'share' button in the UI
- Clicking this button creates a new link, with a GUID-based URL.
- This link is granted READ access to the specific document that it was created for, to *anyone with the link.*
- This mapping is saved in the database.
- This link is a UI link and will navigate to the appropriate page in the UI when clicked. It **cannot** be used from the CLI or to fetch the raw documents.

### Alternatives Considered:
- Globally readable defaults - rejected as it would pollute the front page
- Replace link sharing system with quick 'share with all' button to make the entire namespace *-readable. Rejected as this is too broad in scope and also grants the user access to your entire NS; and also pollutes their front page with your personal NS which was previously hidden.

### Testing Strategy:
Integration and unit testing on CalmHub

### Documentation Requirements:
- Update CalmHub learning guide to use personal namespaces
- Update technical documentation to describe this new addition
- Ensure any permissions model document has this detail too

### Implementation Checklist:
- [ ] Design reviewed and approved
- [ ] Implementation completed
- [ ] Tests written and passing
- [ ] Documentation updated
- [ ] Relevant workflows updated (if needed)
- [ ] Performance impact assessed

### Follow up questions:
- should we have user-scoped domains too, for scratch control work?
- should we have a notion of 'unlisted' where a resource is readable to all but not shown in the top level list?
- Do we need a CLI command to discover the current user's personal NS, or create a link?
- Should links expire?

Start by tracing CalmHub's namespace-existence validation, entitlements panel, front page, document view, and database mappings; the issue does not name specific files or entry points. Review the existing integration and unit tests, then resolve the open design questions before implementing personal namespaces and UI-only link sharing. Done means the feature works with permissions, tests pass, and the listed learning, technical, and permissions documentation is updated.

Written by the indexing model from the issue text.